Jarred Sumner 抛出的 99.8%，很容易让人把 Bun 的 Rust 重写直接送上神坛。
但这条消息真正该看的，不是百分号前面的数字，而是数字后面的限定词：Linux、x64、glibc、既有测试套件、实验性 Rust rewrite。
少看一个词，结论就会飘。
和最初那条“6 天迁移 96 万行”的刺激感相比，现在补上的信息更关键：Bun 不是只把代码搬过去了，它至少已经在一个明确平台上跑到了接近既有行为的测试兼容水平。问题也随之变得更硬：这 99.8%，能不能离开测试环境，进入真实项目。
99.8% 说明了什么，也没说明什么
这条消息可以压成几行：
| 项目 | 当前信息 | 不能外推成什么 |
|---|---|---|
| 发布者 | Bun 作者 Jarred Sumner 在 X 发文 | 不是正式稳定版公告 |
| 对象 | Bun 的实验性 Rust 重写版本 | 不是现有 Bun 已全面切换 Rust |
| 结果 | 既有测试套件通过率 99.8% | 不是生产环境 99.8% 兼容 |
| 环境 | Linux x64 glibc | 不代表 macOS、Windows、musl、ARM 同步达标 |
所以，这是一条很强的工程进展信号。
但它不是终点线。
Bun 一直吸引 JS/TS 开发者的点很直接：快，集成度高，想把 runtime、package manager、bundler、test runner 这些东西揉到一起。开发者烦 Node.js 工具链碎片化很久了，Bun 抓住的就是这个痛点。
问题也在这里。
你越想替代 Node.js 生态里的更多层，就越要吞下更多历史包袱。边角行为、老包兼容、文件系统差异、native addon、网络边界条件，都不是宣传页上的性能数字能解决的。
测试通过率高，至少说明 Rust rewrite 没停在“能跑 demo”的阶段。它开始接近已有行为。
这对三类人有用：
- 已经在小项目里试 Bun 的开发者，可以更认真地评估后续版本。
- 工具链作者，要开始留意 Bun 未来行为是否会稳定下来。
- 技术负责人，可以把 Bun 放进观察名单，但还不该直接写进核心生产链路。
目前最该避免的误读是：把测试兼容当生产兼容，把单一平台当全平台，把实验分支当稳定发布。
真正新增的变量，是那串限定词
“6 天迁移 96 万行”讲的是速度。
“Linux x64 glibc 上 99.8% 测试通过”讲的是边界。
前者让人兴奋，后者让人清醒。
这批信息补上了以前标题最容易吞掉的四个限制：平台只覆盖 Linux x64 glibc，结果来自既有测试套件，版本仍是实验性重写，兼容性还没有等同于真实项目表现。
这些限制不是挑刺。运行时项目的难度，本来就藏在限制里。
macOS 怎么样？Windows 怎么样？musl 怎么样？ARM 怎么样？CI 里的通过率能不能转化成用户仓库里的稳定性？性能有没有回归？这些问题现在都还不能靠 99.8% 回答。
尤其是 Bun 这种底层工具。它的用户不是只打开一个网页点点按钮，而是在它上面跑构建、测试、服务、部署。一个极小的行为差异，可能就会变成半夜 CI 红灯。
运行时的 bug 往往不体面，也不浪漫。
它通常长这样：某个依赖包假设了 Node 的一个怪行为，某个路径处理在不同系统上不一致，某个 native addon 在本地能跑、线上炸掉。你很难把这种事故写成漂亮的技术博客，但用户会记很久。
别急着写成 Rust 战胜 Zig
我不太买账“Rust 更香，所以 Bun 改道”这种简单叙事。
语言当然重要。Rust 有内存安全、生态、人才供给、工具链成熟度。Zig 有低层控制、编译体验、系统编程的锋利感。拿两门语言直接排座次，容易热闹，也容易偷懒。
Bun 真正面对的是一笔维护账。
早期项目拼的是速度和锋利。先做出来，先跑起来，先让开发者眼前一亮。
进入运行时这个级别后，账本变了。团队要考虑可维护、可验证、可招聘、可长期演进。你不能只靠少数核心作者的脑内地图撑住一个生态底座。
天下熙熙，皆为利来。放到开源基础设施里，“利”不只指钱，也包括维护效率、风险控制、社区信任和人才供给。
Rust rewrite 的意义如果成立，不在于证明 Zig 输了，而在于 Bun 团队重新计算了长期成本。一个运行时项目要活得久，不能只靠快。快是门面，稳才是地基。
这也是 99.8% 有意思的地方。
它说明重写没有把项目推回原点。至少在一个受限环境里，Bun 已经把大量行为重新对齐了。
但“行百里者半九十”。最后 0.2% 往往不是几个测试那么简单。它可能是平台差异，是极端输入，是历史兼容，是被大量包隐式依赖的怪行为。
很多重写项目死在这里。
前 90% 让团队相信方向正确，后 10% 让团队发现旧系统里藏着多少没人愿意承认的知识。软件重写从来不是“换一种语言再写一遍”。更像搬迁一座还在营业的城市：路不能断，水电不能停，店铺还要照常开门。
这个类比不完全一样，但足够说明一点：重写不是工程洁癖，重写是组织能力考试。
开发者该怎么用这个消息
如果你是普通前端开发者，这条消息不意味着明天就该把所有 Node 项目迁到 Bun。
更现实的做法是：
- 新项目、小工具、内部脚手架，可以继续试。
- 核心生产服务，等跨平台结果、性能数据和真实项目案例。
- 依赖 native addon、复杂构建链、老旧包的项目，别只看测试通过率。
如果你是工具链作者，这条消息更重要。
Bun 如果继续靠近 Node 行为，生态适配成本会下降。但你也要盯紧它的差异边界。因为用户不会区分“这是 Bun 的问题”还是“这是工具的适配问题”，他们只会记住“跑不起来”。
如果你是技术负责人，判断条件更简单：
Bun 可以进入评估。
但不要因为 99.8% 就改生产基线。
接下来真正该看四件事：
- macOS、Windows、musl、ARM 的测试通过率是否跟上。
- 真实项目迁移中包管理、构建、测试、运行时行为是否稳定。
- Rust rewrite 后性能有没有全面回归，尤其是冷启动、I/O、包安装和测试执行。
- 团队能否一边推进迁移一边保持当前版本节奏。
如果这些跟上，Bun 这次重写会成为一次关键换轨。
如果跟不上，99.8% 也可能只是一个漂亮但昂贵的中途站。
我的判断很简单：这事值得乐观，但不值得庆祝太早。
Bun 真正要赢的不是语言之争，而是开发者信任。信任来得慢，走得快。一次兼容事故，比十条性能捷报更容易被记住。
99.8% 是门票，不是奖杯。门票让你进场，奖杯要靠最后那点脏活累活拿。