Bun内存泄漏修复：Claude重写Rust核心代码的深度技术解析

2026年5月11日，Bun创始人Jarred Sumner在社交平台X上发布了一条推文，这则简短声明几乎预示了Zig版本Bun的终结。

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

寥寥数语，标志着一个技术周期的落幕。四年前，Bun因采用Zig语言而独树一帜，成为运行时生态中的一股革新力量；四年后，其创造者用一条推文，为这段技术探索画上了休止符。

这场从Zig到Rust的迁移，其执行速度令人震惊。整个过程仅耗时约六天，涉及96万行代码，并在Linux x64 glibc环境下通过了现有测试套件99.8%的用例。更具戏剧性的是，就在六天前，Jarred本人在Hacker News上还表示这堆代码“根本跑不起来”，并坦言“最终被全部废弃的概率极高”。短短一周内，代码的命运就从“大概率废弃”转向了“即将取代原有实现”。

“整个讨论有些反应过度了。302条评论，全都围绕着一堆目前还无法运行的代码。我们并未做出必须重写的最终决定。而且这些代码最终被全部废弃的可能性其实非常高。

我真正好奇的是：一个实际可运行的版本究竟会是什么形态、其使用体验如何、性能表现怎样，以及让它通过Bun的完整测试套件并达到可维护状态，到底会有多困难。我希望未来能将一个可行的Rust版本与现有的Zig版本进行并排对比评估。”

转折点或许出现在Bun被Anthropic收购之后。它已深度集成到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到Rust迁移指南，将整个迁移过程拆分为Phase A和Phase B两个阶段：前者要求Claude以近乎机械的方式逐文件保留Zig的原始逻辑，即使生成的Rust代码暂时无法编译也在所不惜；后者则逐个crate解决编译、构建和运行问题。文档的细致程度超乎寻常，它规定了文件命名规范、crate引用方式，明确禁止使用tokio、rayon、hyper、futures等异步库，禁止使用async fn，要求所有unsafe代码块必须附带SAFETY注释，甚至指示AI在遇到不确定的逻辑时宁可留下TODO标记，也不要自行推测。

换言之，这并非传统意义上的“人工重写运行时”，更像是在利用AI对整个Bun代码库进行一次大规模、高保真的语义映射与转译。

随后几天，项目的推进速度开始超越常规软件工程的范畴。

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

当时的Rust版本已经能够显示帮助菜单（尽管版本号仍有错误，部分格式化文本也未正确替换），`bun run`和`package.json`脚本也已能够执行。这意味着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仓库：

“Claude Code的主进程表现出严重的内存泄漏，RSS内存在约3小时的短会话中从约1.7GB增长到14GB以上。泄漏点位于Bun运行时的WebKit Malloc分配器中，而非用户空间的Ja vaScript分配。”

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

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承担着全球级别的工作负载，却维持着更小的待处理问题列表；而仍处于早期阶段的Bun，却已经被问题淹没了。”

不止于内存泄漏：Bun与Zig的哲学分歧

内存泄漏并非唯一的问题。Bun和Zig社区之间，还存在一道更深层的理念裂痕。

这场迁移之所以迅速引爆讨论，另一个原因是：Bun本身一直是Zig生态中最成功、也最具代表性的明星项目之一。过去几年，Bun凭借Zig带来的性能优势，与使用C++的Node.js、使用Rust的Deno形成了鲜明对比。某种意义上，Bun几乎一度成为Zig在现代基础设施领域的“活体广告”。

但问题在于，Bun团队此前其实已经fork了Zig。他们曾宣称，通过在macOS与Linux上引入LLVM并行代码生成，debug编译速度提升了四倍。但这些优化始终无法合并回Zig官方仓库，其中一个关键原因，就是Zig社区极其严格的“no-AI policy”——禁止AI生成issue、PR甚至评论。

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

这种冲突，在Anthropic收购Bun后开始显得格外讽刺。

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

所以，当Jarred说“厌倦了修复内存泄漏”时，他心里可能还有一句未言明的话：Zig这条路，在当前的工程现实下，已经难以为继。

这就是2026年5月重写前夜的现实：四年积累的96万行Zig代码，4700个未解决问题，一个被内存泄漏拖累至占用14GB的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不是靠‘感觉编码’的垃圾，而且开发它的人对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合”。

但无论如何，这扇门已经被彻底推开。以后当你的技术负责人说“我们要把代码库从X语言重写成Y语言”时，他不会再问“需要几个月”，而是会问“Claude需要几天”。

速度飙升的时代，信任与质量需要新的锚点。

参考链接：

https://x.com/jarredsumner

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

https://www.devclass.com/software/2026/05/11/anthrophics-bun-team-trials-port-from-zig-to-rust/5237835

https://thenewstack.io/bun-developers-complaints-anthropic/