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

**Summary:** Bun 团队把运行时从 Zig 迁到 Rust，并用 Claude 跑了一套 AI 辅助的动态工作流。这个故事最值得拆的不是速度本身，而是他们怎么验证这次迁移：测试套件不删不改、对抗性审查、模糊测试、灰度发布、unsafe 代码收敛——这些环节撑不撑得住，才是 AI 辅助大规模移植能不能落地的真正判据。

- Canonical: https://markhuang.ai/zh/news/bun-rust-rewrite-validation-test
- Language: zh-CN
- Author: [Mark Huang](https://markhuang.ai/about)
- Published: 2026-07-08
- Section: News
- Tags: AI, Bun, Rust, 开发者工具, 代码审查
- Source: [Bun Blog](https://bun.com/blog/bun-in-rust)
- License: https://creativecommons.org/licenses/by-nc/4.0/

---

![卡通工程实验室把金色代码块送过审查关卡，变成锈色模块](https://cdn.markhuang.ai/news/bun-rust-rewrite-validation-test/hero.webp)

*Bun 的 Rust 重写是个速度故事，但我更在意的是速度背后那套验证体系。*

[Jarred Sumner 7 月 8 日发的 Bun 博文](https://bun.com/blog/bun-in-rust)说，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。真正的论点是：就这个代码库、这个团队、这种稳定性画像而言，让编译器更清楚地看到所有权规则，是行得通的。

![卡通修复流水线把开裂的金色代码块变成带安全护栏的锈色模块](https://cdn.markhuang.ai/news/bun-rust-rewrite-validation-test/why-it-matters.webp)

*这次重写最站得住的理由是结构性的：把常见的清理类错误，从后期调试挪到更早的反馈环节。*

## 工作流本身才是新闻

博文提到，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 万美元。这不是便宜的魔法，是昂贵的自动化加上一套非常庞大的现有测试。

> **Info:**
>
> 我从中学到的不是"让模型重写整个仓库"，而是"把迁移拆成许多小的工作队列，强制分离审查上下文，让测试套件不依赖实现语言"。

## 质疑是合理的

围绕这次重写的怀疑不难理解。[合并的 PR](https://github.com/oven-sh/bun/pull/30412) 体量巨大，[DevClass 报道 5 月那次合并](https://www.devclass.com/ai-ml/2026/05/15/anthropics-bun-rust-rewrite-merged-at-speed-of-ai/5240541)时，称之为一次让社区意外的 AI 速度事件，新增超过一百万行代码。[Hacker News](https://news.ycombinator.com/item?id=48073680) 和 [Lobsters](https://lobste.rs/s/lapqbz/bun_s_rust_rewrite_has_been_merged) 上的讨论集中在可审查性、unsafe Rust、测试能不能覆盖得够，以及一次快速的 AI 辅助移植是否值得在生产环境信任。

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

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

![卡通天平一端是快速流过的代码块，另一端是审查工具、锁和测试关卡](https://cdn.markhuang.ai/news/bun-rust-rewrite-validation-test/tradeoff.webp)

*速度不是最终指标。真正有用的指标是：团队还能不能检查、测试、接管、回滚那些快速移动过的东西。*

## 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 启动遥测更快。这些都是有意义的信心信号，但不是验证的终点。

![卡通运维间监控多条并行的代码通道穿过测试、安全和发布关卡](https://cdn.markhuang.ai/news/bun-rust-rewrite-validation-test/workflow-risk.webp)

*合并之后才是真正持久的活：灰度反馈、模糊测试、安全审查、unsafe 收敛、事件响应。*

## 我的结论

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

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