Bun 的 Rust 重写：一封来自 Zig 社区的公开信
| 2026-05-16
本文英文版本发布中我个人博客中。
在讨论这次重写之前，有一件事必须说清楚，因为没有人说。
Bun 能站在今天这个位置，是因为 Zig。
Jarred 当年选择 Zig，不是因为它”够酷”，是因为 Zig 让一个小团队能在没有 GC、没有沉重运行时的情况下，快速堆出一个高性能 JS runtime 的原型。Zig 的低摩擦、直接操控内存、简洁的 C 互操作，是 Bun 早期能以极小规模打出性能旗帜的核心原因。你今天看到的 Bun 的架构、数据结构、底层设计——那是 Zig 塑造的。
Jarred 自己也说：架构不变，数据结构不变。
翻译成大白话：Rust 重写继承的那套骨架，是 Zig 建的。 用 Zig 打地基，用 Zig 跑通产品，用 Zig 拿到融资，然后等公司被收购、羽翼丰满之后，切换到更”主流”的技术栈——这没什么问题，这是正常的商业决策。硅谷创业公司的技术债就是这么运作的。
我们 Zig 社区不需要 Bun 的感谢，但请不要假装这次重写是因为 Zig 本身不行。
真正的问题，没人敢说
现在，让我们来讨论这次重写本身。
6755 个 commit，分支名 claude/phase-a-port，5 月 8 日开 PR，5 月 14 日合并。
六天。一个生产级 JS runtime 的全量重写，六天合并。
你可以把这个数字在脑子里放一秒。
软件工程里有一条基本原则：你不理解的代码，不应该运行在生产环境。 不是因为它一定有 bug，是因为当它出 bug 的时候，你不知道从哪里开始找。这条原则不是保守主义，是可维护性的底线。
6755 个 commit，没有一行是人类写的。PR 的 reviewer 列表：coderabbitai[bot] review 了，claude[bot] review 了，唯一的人类 reviewer alii 的状态是 Awaiting requested review——还没看。
Claude 写的代码，Claude 在 review。这个闭环在逻辑上不是不可能，但它意味着：这个代码库目前没有任何一个人类真正读过它。
“测试全过”不是你想的那个意思
这里会有人反驳：测试套件全平台通过，这不就是验证吗？
不是。
测试套件验证的是已知行为在已知路径下的正确性。它不验证：
- 错误路径是否被正确处理
- 边界条件在压力下的行为
- 并发场景下的状态一致性
- 内存模型在极端情况下是否符合意图
Jarred 自己也承认：跨 JS 边界 re-enter 的内存问题，Rust 编译器管不了，还是靠人。
而这些靠人的部分，现在没有人 review 过。
更根本的问题是：AI 翻译代码的方式是局部语义等价，它保证每个函数在孤立状态下的行为与原版一致，但它不理解函数之间的全局不变量——那些没有写进测试、只活在原作者脑子里的设计约束。这些约束，可能在今天的测试里看不出来，但会在六个月后某个特定的生产负载下以一种完全不可解释的方式崩溃。
这不是在黑 Claude。这是任何翻译工具——包括人类程序员——在没有充分 review 的情况下都会面临的问题。规模是 6755 个 commit 的时候，这个风险被放大了 6755 倍。
被收购之后，风险的承受者变了
这里有一个政治经济学的维度，技术讨论通常会忽略。
Bun 早期是 Jarred 一个人押注。那时候用 Zig、快速迭代、接受技术债——这是合理的创业逻辑，风险自担。
现在 Bun 被大公司收购了，用户基数是真实的生产系统。这次重写的风险承受者，不再是 Jarred，而是所有在生产环境跑 Bun 的工程师和他们背后的用户。
Jarred 说，这个版本目前还在 canary，正式发布前还有优化和清理工作要做。
Canary 是一道防线，但它不是人类 review。优化和清理是代码质量的问题，不是理解问题。一个团队没有人完整读过的代码库，不管测试多全、canary 跑多久，它的内部状态对维护者而言都是黑盒。
这在未来某次严重 bug 的调试现场，会变成非常现实的痛苦。
Zig 的”问题”被错误地诊断了
让我们回到 Jarred 给出的迁移理由：Zig 代码库里有太多 use-after-free、double-free、错误路径上的内存泄漏。
这是真的。但这个诊断得出”Zig 不行”的结论是错的。
正确的诊断是：在一个以快速迭代为优先的商业项目里，手动内存管理的认知税超过了团队的预算。 这不是 Zig 的 bug，这是 Zig 的 design goal 和 Bun 的商业模型之间的结构性不匹配。
Zig 的目标用户是：知道自己在做什么、愿意为极致控制力付出代价的系统程序员。TigerBeetle 用 Zig 写出了一个几乎没有内存 bug 的数据库，因为他们的团队文化和项目性质与 Zig 的哲学匹配。
Bun 的团队文化是快速迭代、快速发布、快速修 bug。这和 Zig 要求的严谨内存纪律之间，存在根本张力。这是 Bun 和 Zig 的 mismatch，不是 Zig 的失败。
把”我们团队在这个工具上频繁出错”解读为”这个工具不行”，是归因谬误。锤子不对，但不是锤子的错。
那么，这次重写会 work 吗？
坦白说：短期可能没问题，长期存在结构性隐患。
短期：测试覆盖了主路径，canary 阶段会暴露明显问题，Rust 的编译器保证了一大类内存 bug 不会出现。表面上看一切正常。
长期：这个代码库里有 6755 个 commit 是没有人类完整读过的。当六个月后出现一个诡异的并发 bug，当某个边界条件在特定负载下触发异常行为，调试这个问题的工程师面对的是一个没有人真正理解过的系统。
没有人理解过的系统，不是没有 bug，是 bug 出现时没有人知道为什么。 这两者的区别，在凌晨三点的生产事故里，会变得极其清晰。
这才是这次重写真正的技术赌注：不是 Zig vs Rust，而是 AI 生成的、无人 review 的代码，能否在生产环境里被长期维护。
这个问题，比”测试全过了”复杂得多，也比”Rust 内存安全”深远得多。
答案，我们等着看。
Zig 建了地基，Claude 盖了楼，人类 reviewer 还在路上。
这栋楼能住多久，取决于楼里第一次漏水的时候，有没有人看得懂图纸。