Bun 六天 Rust 迁移深度解析：96 万行代码、13000 个 unsafe，以及 AI 重写软件的边界
2026 年 5 月 11 日，Bun 创始人 Jarred Sumner 在 X 上发了一条推文：
# Bun 六天 Rust 迁移深度解析：96 万行代码、13000 个 unsafe，以及 AI 重写软件的边界
2026 年 5 月 11 日，Bun 创始人 Jarred Sumner 在 X 上发了一条推文：
> "如果我们合并 Rust 重写版本，这将是 Zig 的最后一个版本。"
这意味着：经过六天、由 Claude agent 驱动的大规模迁移，一个涵盖了 96 万行代码、跨越多个平台的 JavaScript runtime，将从 Zig 切换到 Rust。而六天前，Jarred 本人还在 Hacker News 上说"这些代码最后被全部扔掉的概率非常高"。
这是一个真实发生的技术事件，它暴露的不是一个简单的语言选择问题，而是关于 AI 生成代码质量、内存安全哲学、以及软件开发流程的根本性讨论。
背景：为什么 Bun 必须解决内存泄漏
要理解这次迁移，先要理解 Bun 遇到了什么问题。
2025 年 12 月，Anthropic 收购了 Bun，官方定位是"AI 驱动软件工程的重要基础设施"。Bun 深度嵌入到 Claude Code 的链路中——当你安装 Claude Code 时，你实际上也在运行 Bun。它的启动时间约 3ms，而 Python 约 45ms。这个速度差对 AI 编程工具的用户体验至关重要。
但代价随之而来。2026 年 3 月，GitHub Issue #33453 被提交到 Claude Code 仓库：
> "Claude Code 的主进程表现出严重的内存泄漏，RSS 内存在约 3 小时的短会话中从约 1.7GB 增长到 14GB 以上。泄漏位于 Bun 运行时的 WebKit Malloc 分配器中，而非用户空间的 JavaScript 分配。"
更夸张的记录（Issue #11377）：运行 14 小时后，进程占用 23GB 虚拟内存，143.8% CPU，系统完全卡死。
与此同时，Bun 自身的 issue backlog 已经膨胀到约 4700 个 open issues。作为对比，驱动几乎整个互联网的 Node.js 只有约 1700 个。这个数字与用户规模的对比值得注意——Bun 远没有 Node.js 那么成熟，但积压的问题却更多。
这些问题的根源被广泛指向 Zig 本身。Zig 没有垃圾回收器，内存管理完全交给开发者。这意味着正确性完全依赖工程师的经验和注意力。在一个有数百万行代码、涉及文件系统、网络、JavaScript 引擎集成的复杂 runtime 中，遗漏的边界情况会慢慢累积成系统性风险。
技术细节：Claude 是如何六天完成 96 万行迁移的
这次迁移不是传统意义上的"人工重写"，而是一次由 AI 驱动的大规模语义翻译。Bun 团队建立了一个高度结构化的 pipeline：
PORTING.md：迁移路线图
团队创建了一份长达 576 行的 PORTING.md 文档，把整个迁移拆成两个阶段：
Phase A：逐文件忠实翻译
Claude 的任务是逐文件将 Zig 代码翻译成 Rust，即使 Rust 代码暂时无法编译也要继续。这是为了让 AI 不要停下来试图"优化"逻辑——Phase A 的目标是最小化语义偏差，编译问题是 Phase B 的事。
Phase B：逐 crate 解决编译和运行问题
在 Phase A 完成后，逐个 crate 解决类型检查、生命周期、构建问题。
文档对 Claude 的约束极其具体：
- 文件命名规范、crate 引用结构全部指定
- 禁止使用 tokio/rayon/hyper/futures、禁止 async fn
- unsafe 代码必须写明 SAFETY 注释
- 遇到不确定逻辑时**宁可留下 TODO，也不要让 AI 自行猜测**
这套约束背后的逻辑是：Phase A 的优先级是语义等价的正确性，而不是代码质量。代码质量在 Phase B 解决。
迁移规模
- **约 4000 次 commit**
- **约 96 万行代码**
- **六天完成**（其中写代码三天，测试两天）
- 覆盖 Linux x64+arm64 (glibc+musl)、Windows x64+arm64、macOS x64+arm64
5 月 7 日，Rust 版本已经能显示 help menu、运行 bun run 和 package.json scripts，这意味着 JSON parser、AST、logger、module resolver、文件系统遍历等基础能力都已迁移完成。Jarred 当时的原话："JavaScript runtime runs JavaScript."
5 月 9 日，Rust 版本在 Linux x64 glibc 环境下通过了 Bun 既有测试套件的 99.8%。
99.8% 这个数字值得注意：它不是 100%，意味着还有约 0.2% 的边界情况没有覆盖。但考虑到迁移规模和速度，这个数字已经是极高的验证率。
unsafe 的问题
迁移完成后，一个争议点迅速引爆：Theo（t3.gg 创始人）在 X 上指出：
> "uv 包含 35 万行 Rust 代码，有 73 个 unsafe 调用。Bun Rust 移植版有 68.1 万行 Rust 代码，超过 13,000 个 unsafe 调用。"
73 vs 13,000，差了接近 180 倍。社区的批评很快变成"vibecoded disaster"——AI 生成、AI 审核、AI 合并。
Jarred 的回应："今天已经下降了大约 2000。我预计它会稳定在 1 万左右，因为 Bun 的大部分内容都是用 C 和 C++ 编写的，这种情况不会改变。"
这个解释在技术上有一定道理。Bun 的 runtime 集成了 JavaScript 引擎（JavaScriptCore）、文件系统、网络协议栈，这些模块在 Rust 中不可能完全绕开 unsafe。但 13,000 这个数字依然值得追问：
为什么 uv（同样涉及大量底层操作的包管理器）只需要 73 个 unsafe，而 Bun 需要 1 万？
核心原因是两种代码库的定位不同：
- **uv** 是一个纯粹的 Python 包管理器，核心逻辑是 HTTP 下载 + 磁盘写入，不需要与底层 C 库深度绑定
- **Bun** 是一个 JavaScript runtime，要嵌入 JavaScript 引擎、处理 POSIX 文件描述符、调用系统调用——这些在 Rust 中默认都需要 unsafe
但另一个问题是迁移方法：Phase A 要求 Claude 忠实翻译 Zig，而 Zig 代码本身大量使用了 tagged pointer、位运算、非确定性行为（如并发语义分析）。这些在 Rust 中自然需要 unsafe 来绕过借用检查器的约束。Claude 忠实地把这些 unsafe 模式也翻译了过来，而没有在翻译阶段做重新设计。
这正是"忠实翻译"的代价——你得到了语义等价，但失去了在翻译过程中重新设计的机会。
Zig 社区的 anti-AI policy：一个讽刺的背景
这次迁移还有一个容易被忽略的背景：Zig 社区有极其严格的 anti-AI policy。
Zig 基金会的成员 Loris Cro 曾公开表示，大量 LLM 贡献只会制造"幻觉 PR"、"垃圾噪音"以及动辄上万行、根本无法维护的提交。Zig 社区在 2024 年就明确禁止 AI 生成 issue、PR 甚至评论。
而 Bun 团队此前曾 fork 过 Zig，但无法将优化 upstream 回官方。其中一个原因就是 Zig 社区认为 Bun 对 LLVM backend 的修改"不适合 upstream"。
讽刺的是：Anthropic 恰恰是 AI coding 浪潮最激进的推动者，而 Claude Code 深度依赖 Bun。Zig 社区全面封禁 AI 生成代码，而 Bun 团队用 Claude agent 把 Zig 本身迁移出了 Zig。
这不是一个技术选择，这是一场哲学冲突。Bun 选择了速度，而 Zig 选择了信任。
更广阔的趋势：AI 正在改变重写的经济学
Bun 的案例不是孤例。2026 年，多个团队在用 AI 加速代码库迁移：
- **Cloudflare**：一周内用 AI 重新实现了 Next.js API 的大部分能力
- **Ladybird 浏览器**：两周内将 JavaScript 引擎从 C++ 迁移到 Rust
- **esbuild**：Jarred 当年手工移植花了三周；用 AI 做类似的迁移，估算时间是几天
Jarred 本人也说过："这种 pipeline，任何 VC 支持的 OSS 或者有大量 GitHub issues 的公司都能搭建。我预计开源软件会走向完全相反的方向——未来甚至可能变成'禁止人类贡献代码'。人类依然会负责讨论问题、决定优先级，但真正写代码、提交 PR、回复和处理反馈、完成实现的工作，最终都会由 LLM 来完成。"
如果这个预言成真，软件工程将发生根本性的范式转移：
- 代码的来源从"工程师手写"变成"AI 生成 + AI 审核"
- 重写的成本从"月"变成"天"甚至"小时"
- 代码审查的逻辑从"人类 review 人类代码"变成"AI 辅助审查 AI 代码"
这带来了新的信任问题：当代码是 AI 生成的时候，谁对代码质量负责？
这次迁移揭示的 AI 重写边界
从 Bun 的案例，我们可以提炼出 AI 重写代码的真实边界：
AI 擅长的事情
- **跨语言语义翻译**：将一种语言的逻辑逐行翻译成另一种语言，Claude 做到了 99.8% 的测试通过率
- **大规模重复性工作**：96 万行代码的迁移，在传统工程中可能需要数月，AI 六天完成
- **保持行为一致**：通过测试套件验证，Claude 保持了原有行为
AI 不擅长的事情
- **架构级重新设计**：Phase A 的"忠实翻译"策略保留了原始架构的问题（比如 tagged pointer），而没有在翻译过程中重新设计
- **边界情况判断**：当原始代码本身存在未定义行为时，忠实翻译会把这个不确定性带入目标语言
- **代码质量初始值**：13,000 个 unsafe 不是 Rust 代码质量的失败，而是翻译策略的必然结果
关键发现：移植后的 unsafe 数量取决于原代码的 unsafe 密度
这是 Bun 案例最重要的技术洞察之一：
> 一个用 Zig（无 GC，手动内存管理）写的复杂 runtime，翻译成 Rust 后 unsafe 数量自然会很高，因为原代码的内存管理策略本来就需要 Rust 中的 unsafe 来表达。
反过来想：如果把同样的 96 万行从 Rust 迁移到 Zig，unsafe 的数量会是多少？可能也是类似的量级。
这意味着 unsafe 的数量不是代码质量的代理指标，它更多反映的是原始代码的架构特性。真正的问题不是"13,000 个 unsafe"，而是"这 13,000 个 unsafe 每个都安全吗"？
未解决的问题
Bun 的 Rust 版本目前（截至 2026 年 5 月中旬）尚未合并，v1.3.14 尚未发布。以下问题仍未解答：
1. 测试通过率 99.8% 意味着什么：那 0.2% 的边界情况是否会出现在生产环境中？
2. 13,000 个 unsafe 的安全性：每个 unsafe 都有 SAFETY 注释吗？review 流程是什么？
3. 与 Zig 社区的关系：Bun 是 Zig 最大的明星项目，如果 Bun 离开，Zig 生态会受到怎样的影响？
4. 长期维护性：AI 生成的代码在长期维护中会出现什么问题？
总结
Bun 的 Rust 迁移是一个技术事件，也是一个行业信号。
它证明了：AI 可以以人类无法企及的速度完成大规模代码迁移，6 天 96 万行的速度打破了"代码重写需要数月"的传统认知。
它也暴露了 AI 重写的典型问题：忠实翻译保留架构债务、unsafe 泛滥、缺乏人类判断的介入。
但更根本的问题不是"AI 能不能重写"，而是"AI 重写的代码谁来负责"。这个问题目前没有答案。
Jarred 说"我真的很厌倦为内存泄漏、担忧和花费大量时间进行修复"——Rust 给了他一个出口。但 Rust 不等于安全，unsafe 还在那里，只是换了一种表达方式。
这次迁移的最终结果会告诉我们一件事：AI 生成代码的质量瓶颈，到底是 AI 的能力问题，还是人类审核流程的缺失问题？
这个问题，比 13,000 个 unsafe 本身更难回答。
---
参考链接：
- [Jarred Sumner X](https://x.com/jarredsumner)
- [Bun commit 46d3bc](https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd5730ef1549e88407701a5)
- [Claude Code Issue #33453](https://github.com/anthropics/claude-code/issues/21965)
- [Theo Yonge X](https://x.com/t3dotgg)（对比数据来源）
- [infoQ 中文报道](https://www.infoq.cn/article/r63e4S6ZyxrGjfIOV96v)