@bli22ard #24 不过这么多人都看错，不怪你，得怪作者毫无必要地放了很多计算过程当作例子，网站文本存在误导，“修复浮点精度问题”但实际上只是显示上，而不是给出一个精确的计算结果。
然后 11 楼举了的例子也有一定误导，我用高精度库了更可能是因为我需要准确的结果，而不是为了数字转字符串看起来好看，这种情况下根本没有可比性。
这个库本身就是只有 number 类型到 string 类型转换，这么一个目的和功能。给定一个数字，返回一个字符串，就这么简单，甭管输入哪里来的，用户提供的，库作者想管也管不了。做 OJ 的时候也没人问 input 怎么来的吧。

不过本来我也不太看好这个库，为了这点功能徒增太多了复杂实现，
如果本身就要精度正确，那直接上精度库就好了，
如果要裁剪小数部分，那 toFixed 就可以了，去末尾 0 那就再加个正则替换。
如果为了智能判断高熵部分并展示……我不知道什么情况下会有这样一个需求，为什么要去在乎一个比 epsilon 小很多的噪音，就算如此，展示比 epsilon 小的值，为什么要做字符比较而不是基于数学方式去判断（例如 for 循环递增提取 5 位移到小数点后，tofixed(5)判断是否等于 1 或 0 ，而不是连续比较 5 个 0 或者 5 个 9 ）
我很怀疑原作者的精神状态……

@bli22ard #24 3000004/1000000 得来的可不可以？来自于网络的数据源很难理解吗？你管人家怎么来的，现在问题就是要展示这个数据，而你非要给计算上高精度库，关键是这个情景下就不涉及计算啊。
楼主热得快炸了，你就非得让楼主开空调？

@RoyCho #48 他图没挂，imugr ，换个好点的梯子节点就能看到了

@bli22ard #22 怎么还没绕过这个弯，就不是精度的问题。会取近似值的，epsilon 都远远大于精度误差，根本没必要上高精度库，高精度库也解决不了显示问题。
就假设我有一个原始就是 0.3000004 的数（不是通过计算得来的，可能是网络，可能是可视化的数据集，总之这个数字本身就是这个形式），不需要计算，直接显示成人类可读字符串表示，这个情况你用高精度库有什么意义吗

这俩的光辉事迹都说烂了，哪怕站内搜一下
别说证书过期，大家巴不得域名过期服务终止拍手称快

大包 steamdb 看了下基本隔俩月就会打折，9 月底有秋促，应该会打折，大约 50 块

说计算精度需求的都跑偏了，网站里面的示例很清楚了，就是为了解决数字格式化的问题，避免因为精度误差导致显示的数字过长或过早使用科学计数法.

不过 100 多行还是有点多了，网站的对比看下来，toFixed 其实很符合要求，只是不会移除尾部 0 ，那么其实再替换下尾部 0 就够了，一行解决
200.0003.toFixed(3).replace(/(\.?|(?<=\.\d+))0+$/,'')
(?<=\.\d+) 就是确保处于小数部分，避免移除了整数部分的尾部 0 ，可能还有其它边界情况没考虑，差不多这个意思。

https://ex.noerr.eu.org/t/1053497
https://ex.noerr.eu.org/t/1057993
https://ex.noerr.eu.org/t/1149621
bootcdn 等被黑产接手投毒，这题年年考年年错

假设跨域情景下的三个角色：用户（以及使用的浏览器），用户访问的网站 A ，网站 A 请求的网站 B 。
首先要明确，跨域规则究竟是在防谁，是为了解决什么问题？
用户访问网站 A ，或者用户访问网站 B ，网站与自身的互动都是同源的，被浏览器信任。
用户访问网站 A 时与网站 B 产生互动，用户可能并不知道会涉及网站 B ，网站 B 也不能信任来自其它前端的不可靠输入，这样的互动是浏览器所要阻止的。
所以，跨域规则是在防当前访问的网站 A 的恶意操作，保护用户与网站 B 之间的数据安全。
如果网站 B 允许网站 A 的跨域请求，那么实际上跨域保护的作用已经结束了。

再来看第一个问题，
> “我做为可能有恶意脚本的黑客……我的恶意 js……”
这里假定了网站 B 是恶意方，用户访问的网站 A 是正常的，但如果网站 A 都已经请求了恶意 js ，那网站 A 还是清白的吗？
OP 在 20L 举了一个 CDN 投毒攻击的例子，但你首先要想到，在 CDN 投毒之前，这一切是正常运作的，网站 A 请求了网站 B 的资源，网站 B 允许网站 A 的跨域请求。
后来其中某一方背叛了信任，虽然是不同源，但这根本不是跨域规则所要解决的问题，也就是需要禁止的跨域资源访问（非法请求访问合法资源），这直接就相当于是注入代码了。

第二个问题，
> “它咋知道我的请求带不带身份呢”
你没写过附带身份凭证的前端请求？你不明确附带身份凭证，那浏览器就不会发送附带身份凭证的请求。凭证是由浏览器管理的，你无法在前端代码中修改跨域请求附带的凭证 https://fetch.spec.whatwg.org/#forbidden-request-header
> “这个服务端必须是为什么要必须明确呢？如果不明确会怎么样呢？ ”
同样地，在跨域的语境下，你要搞清楚哪方是攻击方，哪方是受保护方（响应端、用户是被保护方，请求端是潜在的攻击方）。
不明确就说明后端根本没有考虑到可能有来自不明源的攻击，既然不遵循浏览器的安全规则，浏览器就当你是需要被保护的对象，禁止一切风险行为。

一般是这个流程：
在尽量不与现有 issue 重复的情况下，先针对问题提个 issue ，跟维护团队/合作者探讨下是什么类型的 issue ，原因是什么，是否有必要修复（确定完维护团队会给 issue 打一系列 tag ），这个阶段叫 triage ，一般需要最新版本的最小化复现，以便确定问题。
你可以同时在正文中表示愿意针对这个 issue 提交代码贡献，如果确定需要修复并且维护者愿意让你提交代码（也可能由于已有人在处理这个问题，就不需要你出力了），就进入敲代码提 PR 阶段。
PR 阶段会有人来 review ，双方确保最终代码正确、可维护、符合项目风格，如果没问题了，等人合并 PR 就结束了。
如果 triage 阶段确定问题已修复/是个误会/非计划，那就没必要提 PR 了，避免敲完代码后发现实际没有问题/工作重叠等问题。你现在就是遇到这种情况了😂，合作者说更可能是因为路径指向了过时的教程和文档，于是你可以：
1. 基于最新代码尝试复现，如果确定修复了，可以表示确实是个误会，新版本没有这个问题，然后关闭 pr 和 issue 就行了。
2. 如果你愿意更进一步，可以尝试解决路径过时的问题（在另外的 issue 和新的 PR 里完成）。

之前有看老菊的视频，没想到能在这里看到作者，恭喜圆梦

@HENIMAL00 #9 怎么迁移的，用 U 盘？那不一定是新电脑移除的，每个环节经过的电脑都要看一下

安装 git 时不是有选项添加到环境变量，勾上就行了（忘记勾了那就手动加一下，一样的）

@UnluckyNinja #13 1.103.1 修了

cf worker 可以反代，tos 里只写了禁止用于非法活动等，加下验证别开匿名使用就行，搜下相关案例都是被投诉用于欺诈的，只要别人不能用就不会被当成钓鱼站点了

@ThinkStu #24 害，还以为是啥呢，这不是你自己披露的嘛，知道你 v2 的帐号的人都能把这两者联系起来，这能算开盒嘛？
根据你的截图，直接事实只有当事人发错了链接并撤回，实际上想发的是有关沉浸式翻译争议的帖子 https://ex.noerr.eu.org/t/1042477 ，曝光隐私是你的揣测。
V2 地址辨识度低，手滑发错了过了一会儿才反应过来撤回也合情合理（至于复制错的原因，如果是看过往发言查成分说实话也正常，V2 不会隐藏二手交易的帖子，如果你限制了发帖查看，那二手相关帖子就变成唯一能看的新开帖记录了）。就算他从来没发错过，从后面新链接过来的人依旧可以从你个人主页里找到那条二手交易，把这当成曝光隐私有点小题大作了

单独说下第一点，他并不是假开源，而是先开源后闭源，和其它知名工具的不同之处在于，他用了一个新的闭源版本相关的仓库替换掉了原本的开源仓库，原仓库被改名了（不用说大家也知道是一步臭棋），同时在新仓库里并没有说明这一点，导致很多人没发现新仓库其实不是开源的那个版本，就比如你提到的那个帖子的楼主。

开源源码在 https://github.com/immersive-translate/old-immersive-translate ，
3 年前归档，你去 webarchive 能看到 23 年 2 月以来一直可访问，帖子 23 年 8 月，所以其实是帖主搞错了

顺便贴两个链接：
稍早一些的帖子 https://ex.noerr.eu.org/t/1151127
应该是作者本人的回应 https://ex.noerr.eu.org/t/1151145

大家都在往坏的方向解读：你禁止第三方 api key 是为了推广收费服务。
你需要专门针对这个视角回应一下。

如果单纯是为了防止小白被骗（但这实际上不是你们应用的问题，你们也不应该因此影响其它正常用户的使用），
需要解释下为什么没有采取温和或者折中的方案（非常明确的提示或警告，通过隐藏开关启用等等）。

任由事态发展的话恐怕要覆水难收了

https://github.com/microsoft/vscode/issues/260389#issuecomment-3166309726
等这个 issue closed 再升吧