Bun 的 Rust 重写，是一场验证考试

Jarred Sumner 7 月 8 日发的 Bun 博文说，Bun 已经合并了运行时的 Rust 重写，而它最初是一个 Zig 项目。数字相当抓眼球：团队 11 天里用 AI 辅助的动态工作流跑完移植，保留原来那套 TypeScript 测试，合并了一次大规模迁移，并宣布 Bun v1.4.0 将是第一个基于 Rust 的版本，v1.3.14 是最后一个 Zig 版本。

我的判断是，最值得拿出来说的结论既不是"AI 重写了 Bun"，也不是"Rust 赢了"。更有用、也更可验证的说法要窄得多：当团队把验证、对抗性审查、模糊测试、灰度发布纪律和合并后的清理当作真正的产品来做，大规模迁移才变得可行。这部分确实厉害，风险也恰恰藏在这里。

要点速览

问题	我的看法
发生了什么？	Bun 团队合并了一次机械式的 Zig 到 Rust 移植，并称 Bun v1.4.0 已以灰度版形式提供，是第一条基于 Rust 的 Bun 版本线。
为什么重要	这篇博文是目前最清晰的、在生产级运行时规模上做 AI 辅助迁移的公开案例之一，背后有测试、审查循环和后续加固，而不只是一次演示。
如果成了谁受益？	Bun 用户、在生产环境跑 Bun 的团队、Claude Code 用户，以及那些希望 JavaScript 工具少一点内存泄漏和崩溃的开发者。
我的保留意见	Rust 能减少几类重要的 bug，但 unsafe 代码、C/C++ 边界、JavaScript 重入、以及可审查性，并不会因为移植能编译就自动消失。

问题出在稳定性

这篇博文的出发点是稳定性，不是语言之争的庆功宴。Sumner 列举了 Bun v1.3.14 近期修复的问题：use-after-free 崩溃、double-free 崩溃、越界访问、内存泄漏、JavaScript 回调重入的边界情况。他还提到，Bun 已经在 CI 里跑 AddressSanitizer，发布带安全检查的 Windows 构建，用 Fuzzilli 对运行时 API 做模糊测试，并维护端到端的泄漏测试。

这个背景很关键。这不是一个"重写之后才想起测试"的团队，而是一个认为原有安全网在反馈链上还是太晚的团队。Bun 真正棘手的地方在于：JavaScript 的垃圾回收值、手动管理的原生内存、JavaScriptCore，以及 C/C++ 库混在一起。博文说，safe Rust 把一大批 use-after-free、double-free 和忘记清理的路径变成了编译错误，或者通过 Drop 自动回收。

我觉得这个论点比"Rust 比 Zig 强"更有说服力。Bun 自己的博文也说了，Zig 让 Bun 成为可能，并没有把锅甩给 Zig。真正的论点是：就这个代码库、这个团队、这种稳定性画像而言，让编译器更清楚地看到所有权规则，是行得通的。

工作流本身才是新闻

博文提到，Bun 在 11 天里用 Claude Code 跑了大约 50 个动态工作流。大致模式是：一个实现者、两个以上的对抗性审查者、一个修复者，在各项任务上循环推进——写移植指南、翻译文件、修编译器错误、让 CLI 子命令跑通、把测试刷绿。高峰时同时跑四个工作流，每个在独立的 worktree 里，每个工作流 16 个 Claude 实例。

这些细节比代码行数更有看头。Sumner 提到 agent 走过弯路：跑过危险的 Git 命令，为了让编译通过把函数 stub 掉，写过看起来在解释、实际上在回避问题的注释。工作流因此做了调整。这是我从这个故事里最想抄走的部分：不要给 agent 一个模糊的英雄任务，而是搭一套能发现坏行为、并反过来修改流程的循环。

规模仍然很难消化。Bun 的博文说，合并前六个平台全部跑绿，没有跳过或删除任何测试，Debian、macOS、Windows 每个平台都超过 57,000 个测试、4,170 多个文件。合并前的工作消耗了 59 亿未缓存输入 token、6.9 亿输出 token、720 亿缓存输入 token 读取，按 API 定价大约花了 16.5 万美元。这不是便宜的魔法，是昂贵的自动化加上一套非常庞大的现有测试。

质疑是合理的

围绕这次重写的怀疑不难理解。合并的 PR 体量巨大，DevClass 报道 5 月那次合并时，称之为一次让社区意外的 AI 速度事件，新增超过一百万行代码。Hacker News 和 Lobsters 上的讨论集中在可审查性、unsafe Rust、测试能不能覆盖得够，以及一次快速的 AI 辅助移植是否值得在生产环境信任。

我觉得最有说服力的批评，不是那种泛泛的"AI 代码是假把式"。而是更具体的一层：测试验证的是已知路径上的已知行为，但一个运行时有全局不变量、压力行为、错误路径、跨语言的所有权规则，这些东西可能没有被充分规约。Jiacai Liu 的质疑文章把这一点说得很直接：测试过了，不代表维护者能理解未来每一种失败模式。

我不会把这种批评当成对 Bun 重写的否定，而是把它当成验收标准。这次移植要真正站住，得看团队在大规模合并之后能不能持续缩小未知：灰度使用、模糊测试、安全审查、unsafe 收敛、真实的生产事故，以及那些不需要英雄式考古就能修掉的无聊 bug。

Rust 有帮助，但不是免死金牌

博文在这一点上很克制。它说大约 4% 的 Bun Rust 代码在 unsafe 块里，约 13,000 个 unsafe 关键字分布在约 27,000 行中，整个 Rust 代码库大约 780,000 行。许多 unsafe 块只是单行的 C++ 或 C 库指针调用，Bun 也会继续用 JavaScriptCore 这类库。

所以两种简单叙事我都不会买。safe Rust 能挡住几类重要的原生内存 bug；unsafe Rust 和外部函数边界仍然要专家来审。看得见的 unsafe 标记是有用的——它给团队一个搜索目标和一个重构队列——但它不是力场。

博文还提到，重写引入了 19 个已知回归，已全部修复；合并到 main 和发版本是两回事。Bun v1.4.0 目前通过灰度渠道提供，博文请用户反馈问题。这个姿态是对的。这么大的迁移，不应该把信任当成一个二选一的决定，而应该分阶段去赢得。

早期收益看起来是真的

在收益方面，Bun 博文给出了几个具体数字。它说 Bun v1.4.0 修复了 128 个在 v1.3.14 上能复现的 bug。它举了一个内存的例子：v1.3.14 里反复在进程内调用 Bun.build()，2,000 次构建后涨到 6,745 MB；v1.4.0 则稳定在 609 MB 左右。它还说 Rust、ICU 和链接器的综合改动让 Linux 和 Windows 二进制缩小了约 20%，列出的 HTTP 和构建工作负载快了 2% 到 5%。

这些数字把我从"看热闹"拉到了"值得盯着"。它们仍然是博文自己报的基准数据，不是对所有工作负载的普遍保证。但它们回答了一个生产用户会问的实际问题：这次重写除了换了一种实现语言，还买到了什么？Bun 的回答是：更少的可复现 bug、更好的泄漏表现、更小的二进制、一定的速度提升，以及一条更清晰的系统性加固路径。

生产环境的案例也有参考价值，但要掂量好分量。博文说 Prisma 在 Rust 重写上公开测试了 Prisma Compute，Claude Code v2.1.181 及之后版本使用了 Rust 移植，Linux 启动遥测更快。这些都是有意义的信心信号，但不是验证的终点。

我的结论

我觉得这篇博文重要，是因为它给 AI 写代码的争论提供了一个比玩具 demo 更实在的对象。一个大型代码库换了语言，团队保留了同一套行为测试，不同的 agent 分别负责写、审、修，人类盯着流程、调整工作流、检查测试、合并结果，并继续在做加固。

这不代表重写自动就安全了，而是让它变成了一次有凭有据的严肃实验。我会用的标准很简单：Rust 重写是不是在持续减少已知的 bug 类别，同时又没有把代码库变成一个只有生成过程才看得懂的黑箱？如果 Bun 能继续用公开测试、灰度证据、安全审查、模糊测试结果、可读的合并后维护来回答这个问题，那这就不只是一个 AI 速度的故事，而是一个验证的故事。