Bun内存泄漏拖垮Claude Code 六天重写96万行AI代码

2026年5月11日，Bun创始人Jarred Sumner在社交平台X上发布了一条简短的推文，却为整个项目的一个时代画上了句号。

“Bun v1.3.14将于明日发布。如果我们合并Rust重写版本，这将是Zig的最后一个版本。”

寥寥数语，宣告了终结。四年前，Bun因选择Zig语言而显得特立独行；四年后，它的创造者用一条推文，亲手为这个Zig版本按下了停止键。那个涉及近百万行代码变更的Pull Request，如今已经静静地躺在了合并列表里。

这场从Zig到Rust的迁移，速度堪称惊人。整个过程大约只用了六天，涉及96万行代码，并且在Linux x64 glibc环境下通过了现有测试套件的99.8%。更具戏剧性的是，就在六天前，Jarred还在Hacker News上评论说，这堆代码“根本还跑不起来”，并且“最后被全部扔掉的概率非常高”。短短一周不到，同样的代码就从“大概率被废弃”变成了“Zig的最后一个版本”。

问题的关键在于，在被Anthropic收购之后，Bun已经深度嵌入了Claude Code的开发链路。过去几个月，开发者社区对Claude Code最大的不满之一，恰恰就是它“越来越像一堆工程债务缝合出来的东西”。内存占用暴涨、CLI卡顿等问题几乎每天都有用户抱怨。后来不少人才意识到，其中相当一部分问题，最终都能追溯到Bun本身的内存泄漏与运行时稳定性问题。

于是，一个颇具讽刺意味的循环出现了：Claude Code被Bun的内存泄漏问题所拖累；然后，Anthropic让自家的Claude去重写Bun；最后，这个重写后的Bun，又将继续回头支撑Claude Code。

甚至有开发者开始半开玩笑地表达担忧：“Bun已经嵌到Claude Code里了。Claude Code现在看起来糟透了。所以我开始担心，Bun是不是也可能糟透了？”

3天写代码，2天测试，就能解决内存泄露？

时间回到2026年5月初，Bun的GitHub仓库里悄然出现了一个名为“claude/phase-a-port”的新分支。在这个分支内部，数十万行由AI生成的Rust代码，与原始的Zig实现并排存在。

同时出现的，还有一份极其详细的PORTING.md文档。

这份长达576行的Zig-to-Rust迁移指南，将整个迁移过程拆分为Phase A和Phase B两个阶段。Phase A要求Claude逐文件、近乎刻板地保留Zig代码的逻辑，即便生成的Rust代码暂时无法编译也没关系；Phase B则负责逐个crate解决编译、构建和运行问题。文档细致到了规定文件命名、crate引用方式，甚至明确禁止使用tokio、rayon、hyper、futures等库，禁止使用async fn，并要求所有unsafe代码块必须附上SAFETY注释。其核心原则是：遇到不确定的逻辑时，宁可留下TODO标记，也绝不能让AI自行猜测。

换句话说，这并非传统意义上的“人工重写运行时”，更像是在用AI对整个Bun代码库进行一次大规模、高保真的“语义投影”。

随后的几天，项目以一种超越常规软件工程认知的速度向前推进。

5月7日，Jarred Sumner发推称，这次Rust迁移已经涉及约4000次提交、96万行代码，当时只剩下3个编译错误。

当时的Rust版本已经能显示帮助菜单，尽管版本号还是错的，部分格式化文本也尚未正确替换成模板变量。更重要的是，“bun run”和package.json scripts已经能够运行，这意味着JSON解析器、AST、日志记录器、模块解析器、文件系统遍历、模块解析缓存等一系列基础能力都已成功迁移。Jarred还补充了一句：“Ja vaScript runtime runs Ja vaScript。”这表明，这个Rust版本已经不再是躺在仓库里的静态翻译稿，而是真正开始执行Ja vaScript代码了。

不过，他当时明确表示：当前状态仍然只是“勉强能动”，绝对达不到交付标准。下一步还需要进行大量代码清理，并让Claude继续攻克测试套件。

有人在这条推文下惊呼：“难道Claude只用了三天就把Zig版Bun重写成Rust了吗？”Jarred的回复是：“按代码量来看，这个说法准确。”

两天后，进度突然跃升到了另一个量级。5月9日，Jarred宣布，Rust重写版本已经在Linux x64 glibc环境下通过了Bun既有测试套件的99.8%。

到这个时候，这件事已经很难再被看作一次随手的试验。至少在Linux这个关键平台上，Rust版本已经近乎完整地验证了原有行为。Jarred解释说，Rust版本“基本上还是同一个代码库”，但Rust编译器可以帮助团队检查类型生命周期，也能在需要时使用析构函数；那些危险的部分会以unsafe的形式暴露出来，看起来更刺眼，但也因此更容易被识别和推动重构。

同一天，他开始透露真正的心声：“我真的很厌倦为内存泄漏、崩溃和稳定性问题而担忧，厌倦花费大量时间去修复它们。如果编程语言能提供更强大的工具来预防这些问题，那就太好了。”

但与此同时，他还在X上向Rust社区请教更底层的问题：Bun原来的Zig代码大量使用tagged pointer来处理事件循环任务、进程退出回调、非阻塞文件I/O等接口；迁移到Rust后，如果直接使用trait或函数指针，可能会带来额外的开销。他仍在寻找一种既不影响性能、又更符合Rust惯用法的实现方式。

也就是说，直到5月10日，Rust版本虽然已经能跑、测试也接近通过，但底层架构其实还没有完全稳定下来。

而就在这种状态下，5月11日，Jarred发出了那条后来引爆整个开发者社区的推文：“如果我们合并Rust重写版本，这将是Zig的最后一个版本。”

问题累积，靠Rust来“一键修复”？

要理解这场迁移的紧迫性，需要回溯到2025年12月Anthropic对Bun的收购。官方的说法是“加速Claude Code能力”，本质上是让Bun成为Claude Code背后的运行时、包管理器、打包工具和测试工具。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仓库：

另一份Issue #11377记录的情况更夸张（后被机器人标记为重复问题并关闭）：运行14小时后，Claude Code进程占用了23GB虚拟内存，CPU使用率达143.8%，导致系统完全卡死。

Zig基金会成员Loris Cro曾公开表示，大量LLM贡献只会制造“幻觉PR”、“垃圾噪音”以及动辄上万行、根本无法维护的提交。而另一位Zig核心开发者则更直接批评Bun fork中的一些实现“不适合upstream”，例如并行语义分析可能导致非确定性行为，而Bun对LLVM backend的模块拆分，也被认为方向错误。

这种冲突，在Anthropic收购Bun后开始显得格外讽刺。因为Anthropic本身，恰恰是整个AI编程浪潮最激进的推动者之一；而Claude Code现在又深度依赖Bun runtime。结果，一边是Zig社区全面封禁AI生成代码，另一边却是Bun团队开始用Claude agent大规模把Zig本身迁移出Zig。某种意义上，这已经不仅仅是一次语言切换，而更像是两种软件工程哲学的正面碰撞。

所以，当Jarred说“厌倦了修复内存泄漏”时，他心里可能还有一句话没说出来：Zig这条路，已经走不下去了。

这就是2026年5月重写前夜的现实：四年积累的96万行Zig代码，4700个未解决的问题，一个被内存泄漏坑到占用十几GB的Claude Code，以及一个与AI世代格格不入的社区氛围。

Jarred的选择？让Claude在六天内用Rust重写一切。

“Anthropic没有逼我”

重写是完成了，但质量呢？

最大的争议来自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++代码打交道，文件系统、网络、Ja vaScript引擎集成这些都绕不开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重写软件的大趋势正在到来

如果说Bun的这次六天重写只是一个孤例，那或许我们还能把它当成“有钱任性”的花边新闻。但事实是，类似的AI驱动极限重写正在多个领域同时发生。

• Cloudflare曾在一周内借助AI重新实现了Next.js API的大部分能力。
• Ladybird浏览器在两周内将自己的Ja vaScript引擎从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需要几天”。

速度上天的时代，信任只能自己想办法落地。