我对Bun的Rust重写的看法

# 我对 Bun 用 Rust 重写的一些想法 来源：https://en.liujiacai.net/2026/05/16/bun-rust-port/ 在讨论《用 Rust 重写 Bun》(https://github.com/oven-sh/bun/pull/30412) 之前，有件事必须说清楚，因为没人愿意提。 Bun 能有今天，靠的是 Zig。 Jarred 当初选择 Zig，不是因为“酷”，而是因为 Zig 能让一个小团队在无需 GC、无重型运行时的情况下，快速搭建高性能 JS 运行时原型。Zig 的低摩擦、直接内存操作以及简洁的 C 互操作，是 Bun 早期能以极小的团队在性能上超常发挥的核心原因。你现在看到的 Bun 的架构、数据结构、底层设计——都是 Zig 塑造的。 Jarred 本人也说过：架构不变，数据结构不变。 说白了：**这个 Rust 重写所继承的骨架，是用 Zig 搭起来的。** 用 Zig 打基础、用 Zig 发布产品、用 Zig 融到资，等公司被收购、发展壮大后切换到更“主流”的技术栈——这没什么不对。这是正常的商业决策。硅谷创业公司的技术债就是这么玩的。 Zig 社区不需要 Bun 的感激，但请别假装这次重写是因为 Zig 本身不行。 ## 没人敢说的真正问题 现在，我们来谈一谈这次重写 (https://github.com/oven-sh/bun/pull/30412) 本身。 6755 个提交，分支名 `claude/phase-a-port`，PR 于 5 月 8 日创建，5 月 14 日合并。 六天。一个生产级 JS 运行时的完整重写，六天合并。 让这个数字在你脑海里停留一秒。 软件工程中有一个基本原则：**你不理解的代码不应该在生产环境中运行。** 不是因为它一定有 bug，而是因为当它出 bug 时，你不知道从哪里开始查。这个原则不是保守——它是可维护性的底线。 6755 个提交，没有一行是人类写的。PR 的审查者列表：`coderabbitai[bot]` 审查了，`claude[bot]` 审查了，唯一的人类审查者 alii 的状态是“等待请求的审查”——压根没看。 代码是 Claude 写的，Claude 审查的。这个闭环逻辑上并非不可能，但意味着：**没有人类真正完整读过这套代码库。** ## “所有测试通过”并不像你想的那样 有人会反驳：测试套件在所有平台上都通过了——这不就是验证吗？ 不。 测试套件验证的是**已知路径上已知行为的正确性。** 它不验证： - 错误路径是否处理得当 - 压力下的边界条件行为 - 并发场景下的状态一致性 - 极端条件下内存模型是否符合意图 Jarred 自己也承认：跨 JS 边界重入时的内存问题——Rust 编译器处理不了，仍然依赖人类。 而那些依赖人类的部分呢？没有人类审查过。 更根本的问题是：AI 是通过**局部语义等价**来翻译代码的——它确保每个函数在隔离状态下与原版行为一致，但它不理解函数之间的**全局不变量**——那些没有写在测试中、只存在于原作者脑海里的设计约束。这些约束可能不会在今天的问题里暴露，但可能在六个月后、在某个特定的生产负载下，以完全无法解释的崩溃形式显现。 这不是在贬低 Claude。这是任何翻译工具（包括人类程序员）在缺乏彻底审查时都会遇到的问题。在 6755 个提交的规模下，这个风险被放大了 6755 倍。 ## 收购后，风险承担者已经变了 这里有一个技术讨论通常忽视的政治经济学维度。 在早期，Bun 是 Jarred 在自己身上赌博。那时用 Zig，快速迭代，接受技术债——这是合理的创业逻辑，风险自负。 现在 Bun 被大公司收购了，它的用户群是真正的生产系统。这次重写的风险承担者不再是 Jarred，而是每一个在生产环境中运行 Bun 的工程师，以及他们背后的用户。 Jarred 说这个版本仍处于 canary 阶段，正式发布前还有优化和清理工作要做。 Canary 是一道防线，但不是人类审查。优化和清理是代码质量问题，不是理解问题。**团队中没有任何人完整读过的代码库——无论测试多全面，无论 canary 跑多久——它的内部状态对维护者来说都是一个黑箱。** 这在未来某个严重 bug 的调试场景中，会变成非常真实的痛苦。 ## Zig 的“问题”被误诊了 让我们回到 Jarred 给出的迁移原因：Zig 代码库有太多 use-after-free 错误、double-free 以及错误路径上的内存泄漏。 这是事实。但由此得出的“Zig 不行”的结论是错误的。 正确的诊断是：**在一个优先快速迭代的商业项目中，手动内存管理的认知负担超出了团队的预算。** 这不是 Zig 的 bug——这是 Zig 设计目标与 Bun 商业模式之间的结构性不匹配。 Zig 的目标用户是：知道自己正在做什么、愿意为终极控制付出代价的系统程序员。TigerBeetle 用 Zig 写出了几乎没有内存 bug 的数据库，因为他们的团队文化和项目性质与 Zig 的理念一致。 Bun 的团队文化是快速迭代、快速发布、快速修 bug。这与 Zig 要求的严格内存纪律存在根本性的张力。这是 Bun 和 Zig 之间的不匹配，而不是 Zig 的失败。 将“我们的团队频繁用这个工具犯错”解释为“这个工具有问题”，是一种归因错误。锤子不合手，但不是锤子的错。 ## 那么，这次重写能成功吗？ 老实说：**短期大概率没问题；长期存在结构性风险。** 短期：测试覆盖了主要路径，canary 阶段会暴露明显问题，Rust 的编译器保证消除了整个类别的内存 bug。表面上一切正常。 长期：这套代码库有 6755 个提交，没有人类完整读过。当六个月后出现一个诡异的并发 bug，当某个边界条件在特定负载下引发异常行为时，调试问题的工程师将面对一个从来没有人真正理解的系统。 **一个没人理解过的系统，并不代表它没有 bug——而是代表当 bug 出现时，没人知道为什么。** 这两种状态的区别，在生产事故凌晨三点时会变得一清二楚。 这才是这次重写真正在赌的技术问题：不是 Zig 对比 Rust，而是**AI 生成且未经人工审查的代码，能否在生产环境中长期维护。** 这个问题比“所有测试通过”复杂得多，也比“Rust 内存安全”深远得多。 答案——我们拭目以待。 *Zig 打了地基，Claude 建起了大楼，人类审查员还在路上。* *这栋楼能住多久，取决于第一次漏水时，有没有人能看懂设计图。* ## 参考