大包 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 里完成）。

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

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

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

@UnluckyNinja #13 1.103.1 修了

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

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

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

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

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

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

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

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

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

@shintendo #4 这瓜好像听过，但印象不深，刚才去回顾了下。现在突然发现，前几天某个帖子颇有种 deja vu 的感觉啊哈哈

游戏开发哪里到那么底层，顶多考虑下用 TCP 还是 UDP

楼主想问的是 SSR 里的水合吧（ Hydration ），服务端返回渲染完的 html ，在客户端根据 html 内容将组件和 DOM 一一对应并绑定事件等。水合基本上是前端框架主导的，后端只需要提供 html 和所需相关信息。

也就是说，如果你想实现 SSR/基于 SSR 的 SSG ，你得找到一个支持 SSR 的组件框架，基于 JS 的有 vue, react, svelte, solid, angular 等等，Laravel 文档的 SSR 说明里提及了 Inertiajs https://laravel.com/docs/12.x/vite#ssr 。

想了解 SSR 原理可以看看 vue 的文档 https://cn.vuejs.org/guide/scaling-up/ssr
以及 vite 的文档 https://cn.vite.dev/guide/ssr.html

因为 vibe coding 和 AI 辅助编程就不是一回事
用 vibe coding 描述时，当事人是不会去看具体代码的

有人专门就两者被错误混用一事写了条博文
https://simonwillison.net/2025/May/1/not-vibe-coding/