2026 年 5 月 11 日，Bun 创始人 Jarred Sumner 在 X 上发了一条推文，Zig 版的 Bun 就被判了死刑。
“Bun v1.3.14 将于明日发布。如果我们合并 Rust 重写版本，这将是 Zig 的最后一个版本。”
就这么一句。四年前，Bun 因为选择了 Zig 而显得特立独行；四年后，Zig 版本被它的创造者用一条推文宣告了终结。
这场从 Zig 到 Rust 的迁移，实际上只花了大约六天，涉及 96 万行代码，并且在 Linux x64 glibc 环境下通过了现有测试套件的 99.8%。而六天前，Jarred 还在 Hacker News 上说这是一堆根本还跑不起来的代码，“最后被全部扔掉的概率非常高”。六天后，同样的代码变成了“Zig 的最后一个版本”。
“整个讨论有点反应过度了。302 条评论，全都围绕一堆根本还跑不起来的代码。我们并没有决定一定要重写。而且这些代码最后被全部扔掉的概率其实非常高。
我只是很好奇：一个真正可运行的版本到底会是什么样、用起来感觉如何、性能如何，以及让它通过 Bun 的测试套件、并真正变得可维护，到底会有多难。我希望未来能把一个可行的 Rust 版本和 Zig 版本真正并排放在一起比较。”
问题在于，在被 Anthropic 收购之后，Bun 已经深度嵌入到了 Claude Code 的链路中。过去几个月，开发者社区对 Claude Code 最大的不满之一，恰恰就是“它越来越像一堆工程债务缝合出来的东西”。内存占用暴涨、CLI 卡顿等问题几乎每天都有人抱怨。而后来不少人才意识到，其中相当一部分问题，其实最终都能追溯到 Bun 本身的内存泄漏与 runtime 稳定性问题。
于是现在出现了一个非常荒诞的循环：Claude Code 被 Bun 的内存泄漏坑惨了；然后 Anthropic 让 Claude 去重写 Bun；最后 Bun 再继续回头支撑 Claude Code。
甚至已经有开发者开始半开玩笑地担心：“Bun 已经嵌入到 Claude Code 中。Claude Code 看起来糟透了。所以现在我担心 Bun 也可能糟透了。”
2026 年 5 月初，Bun 的 GitHub 仓库里出现了一个名为 claude/phase-a-port 的新分支。分支内部，数十万行由 AI 生成的 Rust 代码，和原始 Zig 实现并排存在。
同时出现了一份极其详细的 PORTING.md 文档。
这是一份长达 576 行的 Zig-to-Rust 迁移指南。它把迁移拆成 Phase A 和 Phase B：前者要求 Claude 逐文件忠实保留 Zig 的逻辑，即便 Rust 代码暂时不能编译也没关系；后者再逐个 crate 解决编译、构建和运行问题。文档还细到规定文件命名、crate 引用、禁止使用 tokio/rayon/hyper/futures、禁止 async fn、unsafe 必须写明 SAFETY 注释，甚至要求遇到不确定逻辑时宁可留下 TODO，也不要让 AI 自行猜测。
也就是说，他们并不是传统意义上的“人工重写 runtime”，而更像是在用 AI 对整个 Bun 做一次大规模语义投影。
随后几天里，整个项目开始以一种不太像“正常软件工程”的速度推进。
5 月 7 日，Jarred Sumner 发推称，这次 Rust 迁移已经涉及约 4000 次 commit、96 万行代码，当时只剩下 3 个编译错误。
当时的 Rust 版本已经能显示 help menu，虽然版本号还是错的，部分 formatter 文本也还没正确替换成模板变量；bun run 和 package.json scripts 也已经跑起来，意味着 JSON parser、AST、logger、module resolver、文件系统遍历、模块解析缓存等一整串基础能力都已经被迁过去。Jarred 还发了一句：“JavaScript runtime runs JavaScript。”也就是说，这个 Rust 版本已经不只是堆在仓库里的翻译稿，而是真的开始执行 JavaScript 了。
不过，他当时明确表示：当前状态仍然只是“勉强能动”，绝对不能交付。下一步还要做大量代码清理，再让 Claude 继续啃测试套件。
有人在这条推文下惊呼：“Claude 难道只用了三天就把 Zig 版 Bun 重写成 Rust 了吗？”Jarred 回复说：“按代码量来看，这个说法准确。”
两天后，进度突然跳到了另一个量级。5 月 9 日，Jarred 宣布，Rust 重写版本已经在 Linux x64 glibc 环境下通过了 Bun 既有测试套件的 99.8%。
不仅如此，该版本还在 Linux x64+arm64 glibc+musl、Windows x64&arm64 以及 macOS x64&arm64 上通过了全部测试。
到这个时候，这件事已经很难再被看成一次随手试验，至少在 Linux 这个关键平台上，Rust 版本已经接近验证了原有行为。Jarred 解释说，Rust 版本“基本上还是同一个代码库”，但编译器可以帮助团队检查类型生命周期，也能在需要时使用析构函数；那些危险部分会以 unsafe 的形式暴露出来，看起来丑陋，但更容易推动重构。
同一天，他透露了真正的目的：“我真的很厌倦为内存泄漏、崩溃和稳定性问题而担忧和花费大量时间进行修复。如果编程语言能提供更强大的工具来预防这些问题，那就太好了。”
但与此同时，他还在 X 上向 Rust 社区请教更底层的问题：Bun 原来的 Zig 代码大量使用 tagged pointer 来处理 event loop task、进程退出回调、非阻塞文件 I/O 等接口；迁到 Rust 后，如果直接用 trait 或函数指针，可能会带来额外开销。他还在寻找一种既不影响性能、又更适合 Rust 的实现方式。
也就是说，到 5 月 10 日，Rust 版本虽然已经能跑、测试也已经接近通过，但底层架构其实还没有完全稳定下来。
而就在这种状态下，5 月 11 日，Jarred 发出了那条后来引爆整个社区的推文：“如果我们合并 Rust 重写版本，这将是 Zig 的最后一个版本。”
2025 年 12 月，Anthropic 收购了 Bun。官方说法是“加速 Claude Code 能力”，本质上是要让 Bun 成为 Claude Code 背后的运行时、包管理器、bundler 和测试工具。Anthropic 将 Bun 定义为“AI 驱动软件工程的重要基础设施”，并认为它能够帮助开发者以前所未有的速度构建和测试应用。
Anthropic Claude Code 负责人 Boris Cherney 曾在 Bun 官网的一段视频中解释，Bun 最大的优势之一是极快的启动速度，而这对 AI 编程工具至关重要：
“我们当初在开发 Claude Code 时，评估了很多运行时方案，Bun 几乎是毫无悬念的胜者。它的启动时间大概只有 3 毫秒，而 Python 要慢 15 倍左右。对于 CLI 工具来说，这意味着用户体验是‘丝滑响应’，还是‘明显卡顿’。”
至少从表面上看，Bun 的确很诱人。但真实情况呢？内存泄漏，漏到 Claude Code 都扛不住。
Claude Code 是以 Bun 可执行文件的形式发布的。当你安装 Claude Code 时，你实际上也在运行 Bun。这并非简单的合作关系，而是紧密的依赖关系。
2026 年 3 月 12 日，一个编号 #33453 的 Issue 被提交到 Claude Code 仓库：
“Claude Code 的主进程表现出严重的内存泄漏，RSS 内存在约 3 小时的短会话中从约 1.7GB 增长到 14GB 以上。泄漏位于 Bun 运行时的 WebKit Malloc 分配器中，而非用户空间的 JavaScript 分配。”
另一份 Issue #11377 记录得更夸张（被机器人标记为重复问题并关闭）：运行 14 小时后，Claude Code 进程占用 23GB 虚拟内存，143.8% CPU，系统完全卡死。
Issue #33453 的作者直接点出罪魁祸首是 Bun 的 WebKit Malloc。
与此同时，Bun 自己的问题也在持续发酵。尽管 Bun v1.1.13 在 2026 年 4 月发布时，官方宣称通过更换内存分配器让内存占用下降了 5%，但很多用户并不买账。
Reddit 用户 Xtergo 曾在一篇自称“粗糙调查”的帖子中集中吐槽 Bun 的内存泄漏问题。他写道：“任何新运行时都会有成熟度问题，这些问题最终会随着时间慢慢被修复。但我担心的是，Bun 的路线图看起来更像是在不断叠加新功能，而不是优先解决稳定性和 Bug 修复问题。”
他还表示：“Bun 现在已经变得非常复杂了。如果这些问题继续得不到解决，我怀疑它永远无法达到 Node.js 那种生产级成熟度。”
另一个被频繁提及的问题，则是 GitHub 上大量长期未关闭的 issue。波兰数字会员系统公司 Rewardo 的 CTO Wojciech Maj 曾做过一个对比：Node.js 作为几乎“驱动整个互联网”的运行时，目前大约有 1700 个 open issues；而更年轻、用户规模远小于 Node.js 的 Bun，却已经积累了约 4700 个 open issues。
Maj 写道：“单纯数字不能说明全部问题，但这个差距依然很惊人。Node.js 承担着全球级别的工作负载，却维持着更小的 backlog；而仍处于早期阶段的 Bun，却已经被问题淹没了。”
内存泄漏不是唯一的问题。Bun 和 Zig 社区之间，还有一道更深的裂痕。
这场迁移之所以迅速引爆讨论，还有另一个原因：Bun 本身一直是 Zig 阵营最成功、也最具代表性的明星项目之一。过去几年里，Bun 靠着 Zig 带来的性能优势，与使用 C++ 的 Node.js、使用 Rust 的 Deno 形成了鲜明对比。某种意义上，Bun 几乎一度成了 Zig 在现代基础设施世界里的“活广告”。
但问题是，Bun 团队此前其实已经 fork 过 Zig。他们曾宣称，通过在 macOS 与 Linux 上引入 LLVM 并行代码生成，debug 编译速度提升了四倍。但这些优化始终无法 upstream 回 Zig 官方，其中一个关键原因，就是 Zig 社区极其严格的“no-AI policy”——禁止 AI 生成 issue、PR 甚至评论。
Zig 基金会成员 Loris Cro 曾公开表示，大量 LLM 贡献只会制造“幻觉 PR”“垃圾噪音”以及动辄上万行、根本无法维护的提交。而另一位 Zig 核心开发者则更直接批评 Bun fork 中的一些实现“不适合 upstream”，例如并行语义分析可能导致非确定性行为，而 Bun 对 LLVM backend 的模块拆分，也被认为方向错误。
这种冲突，在 Anthropic 收购 Bun 后开始显得格外讽刺。
因为 Anthropic 本身，恰恰是整个 AI coding 浪潮最激进的推动者之一；而 Claude Code 现在又深度依赖 Bun runtime。结果，一边是 Zig 社区全面封禁 AI 生成代码，另一边却是 Bun 团队开始用 Claude agent 大规模把 Zig 本身迁移出 Zig。某种意义上，这已经不仅仅是一次语言切换，而更像是两种软件工程哲学的正面碰撞。
所以，当 Jarred 说“厌倦了修复内存泄漏”时，他心里可能还有一句话没说出来：Zig 这条路，已经走不下去了。
这就是 2026 年 5 月重写前夜的现实：四年积累的 96 万行 Zig 代码，4700 个未解决的问题，一个被内存泄漏坑到 14GB 的 Claude Code，以及一个与 AI 世代格格不入的社区氛围。
Jarred 的选择？让 Claude 在六天内用 Rust 重写一切。
重写完是重写完了，但质量呢？
最大的争议来自 Theo——t3.gg 的创始人。5 月 12 日，Theo 在 X 上抛出了一组让 Jarred 不得不正视的对比：“uv 包含 35 万行 Rust 代码，以及 73 个 unsafe 调用。Bun Rust 移植版已经有 68.1 万行 Rust 代码，并且有 超过 13,000 个 unsafe 调用。”
73 vs 13,000，差了接近 180 倍。Jarred 几乎立刻回应：“今天已经下降了大约 2000。我预计它会稳定在 1 万左右，因为 Bun 的大部分内容都是用 C 和 C++ 编写的，这种情况不会改变。”
平心而论，这种对比确实不完全公平。uv 是一个相对纯粹的 Rust 项目，而 Bun 需要与大量底层 C/C++ 代码打交道，文件系统、网络、JavaScript 引擎集成这些都绕不开 unsafe。Jarred 的解释在技术上有道理。但网友们在意的不只是数字。开发者社区很快把矛头指向了另一个维度：流程。
网友 Aashish Ranjan Singh 在 X 上写道：“UV rust 是由真正的开发人员编写的，每一行代码都经过了审查。Bun rust 由 Agents 编写，由 Agents 审核，并由 Agents 批准和合并。完全在意料之中的结果 ”
另一位用户 HSVSphere 则更不客气：“uv 不是 vibecoded 的垃圾，而且开发它的人对 Rust 非常了解。但 Bun 就完全不同了，它简直是一场风格灾难。用 Deno 吧。”
还有人把矛头指向了收购方。开发者 Anthony GG 在 X 上直言：“我开始觉得 Anthropic（收购了 Bun）正在强迫他们用 Rust 重写，这样他们糟糕的工程团队就可以通过怂恿 Claude 来搞砸它。Zig 虽然不错，但由于 Zig 每个月都会进行重大更改，训练数据总是过时。仅供参考。”
面对这种“被迫重写”的猜测，Jarred 亲自下场否认：“没人逼我这么做。”
但“vibecoded disaster”这个词已经精准地刺中了许多人的不安：六天、96 万行、AI 生成、AI 测试，最后带着 1 万个 unsafe 直接合并？
如果说 Bun 的这次六天重写只是一个孤例，那或许我们还能把它当成“有钱任性”的花边新闻。但事实是，类似的 AI 驱动极限重写正在多个领域同时发生。
Cloudflare 曾在一周内借助 AI 重新实现了 Next.js API 的大部分能力。
Ladybird 浏览器 在两周内将自己的 JavaScript 引擎从 C++ 迁移到了 Rust。
Jarred 自己也在 5 月 3 日发过一条推文：“这种 pipeline，任何 VC 支持的 OSS 或者有大量 GitHub issues 的公司都能搭建。更普遍地说，它可以用于自动修复用户报告的 bug。Opus 4.7、4.6 甚至 4.5 都能轻松做到。”
他甚至在更早的时候预言过：“我预计开源软件会走向完全相反的方向——未来甚至可能变成 ‘禁止人类贡献代码’。人类依然会负责讨论问题、决定优先级，但真正写代码、提交 PR、回复和处理反馈、完成实现的工作，最终都会由 LLM 来完成。”
Bun 的这次重写，正是这句话的第一次大规模公开演练。它证明了 AI 能够以人类无法企及的速度完成跨语言迁移——六天 vs 三周（Jarred 当年手工移植 esbuild 的时间）。它也暴露了 AI 重写的典型问题：缺少人类审查、unsafe 泛滥、流程变成“AI 写、AI 审、AI 合”。
但无论如何，这扇门已经被彻底撞开了。以后当你的 CTO 说“我们要把代码库从 X 语言重写成 Y 语言”时，他不会再问“需要几个月”，而是会问“Claude 需要几天”。
速度上天的时代，信任只能自己想办法落地。
后记：Jarred 称对 Rust 版本“非常有信心”，但 v1.3.14 尚未合并。Zig 版暂缓执行。
参考链接：
https://github.com/oven-sh/bun/commit/46d3bc29f270fa881dd5730ef1549e88407701a5
https://github.com/anthropics/claude-code/issues/21965
https://github.com/anthropics/claude-code/issues/11377#issue-3609559118
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。