youtube 很多 AI 音乐专辑，也不标明，2 天出产十首，看过几个音乐串流后，推荐里就全是这种，黄豆流汗了

当某个网站在未先由你交互，主动发来一封邮件：
- 如果是消息推送，例如新闻、博文、安全事故报告等：OK ，可以点击链接，开启“只读模式”，只看不输入任何内容，不进行任何风险操作
- 请求用户更新密保 2FA 等，任何需要输入的情况：不要从邮件链接进入相关服务，而是从你的收藏夹或手动输入/浏览器联想进入官方网站或 SNS 帐号，验证官方推送是否确有其事，再继续操作。

1. 信任对应证书
2. 如果不想信任证书，只需要自动填充，且密码安全性不重要，那就直接写个油猴脚本填充下就行了

https://github.com/RVC-Boss/GPT-SoVITS
https://github.com/RVC-Project/Retrieval-based-Voice-Conversion-WebUI
TTS 用上面的，SVC 用下面的，没上手用过，只是有所耳闻

windows 应该不需要额外安装别的，一直用的下面这个，忘记从哪个 stackoverflow 捞来的了
Host github.com
User git
ProxyCommand connect -S localhost:7890 %h %p
Hostname ssh.github.com
Port 443

现在系统基本都会预分配与显存等量的内存给显卡用于传输数据，8g 根本不够用的，加内存吧

@UnluckyNinja #15 我更诧异的是，你能下下来令牌却不知道怎么登，我十分怀疑你下的这个令牌 app 的安全性

登陆时开代理呗，登陆完后不开代理也能用令牌

@bli22ard #30 是的这些全是误导，他又不处理计算，都是 js 运行时自己计算，运算结果作为真正参数调用这个库函数，放这些算式纯纯误导。
他本身就是想解决“显示”有精度误差的数字的问题（作为其中一个功能但不是唯一功能），但正常人都会去想引入高精度库直接解决精度问题，而引入高精度库并不能解决“输入本身是一个有噪音部分小数的显示问题”，which 正是这个库“真正想解决的问题”（尽管他的实现让人感觉是不是被 AI 带坏了）
但愿你绕过来了

@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://www.v2ex.com/t/1053497
https://www.v2ex.com/t/1057993
https://www.v2ex.com/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 里完成）。