6 天、96 萬行AI代碼、直接合并！Claude Code 被 Bun 的內存泄漏拖垮，Bun 讓 Claude 親手重寫了自己

編譯 | Tina

2026 年 5 月 11 日，Bun 創始人 Jarred Sumner 在 X 上發了一條推文，Zig 版的 Bun 就被判了死刑。

“Bun v1.3.14 將于明日發布。如果我們合并 Rust 重寫版本，這將是 Zig 的最后一個版本。”

就這么一句。四年前，Bun 因為選擇了 Zig 而顯得特立獨行；四年后，Zig 版本被它的創造者用一條推文宣告了終結。

這個近百萬行代碼變更的 PR 如今已經被合并。

這場從 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 也可能糟透了。”

3 天寫代碼 2 天測試，就能解決內存泄露問題？

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 這個關鍵平臺上，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 的最后一個版本。”

問題累積，靠 Rust 來“一鍵修復”？

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 日，一個編號 的 Issue 被提交到 Claude Code 倉庫：

“Claude Code 的主進程表現出嚴重的內存泄漏，RSS 內存在約 3 小時的短會話中從約 1.7GB 增長到 14GB 以上。泄漏位于 Bun 運行時的 WebKit Malloc 分配器中，而非用戶空間的 JavaScript 分配。”

另一份 Issue 記錄得更夸張（被機器人標記為重復問題并關閉）：運行 14 小時后，Claude Code 進程占用 23GB 虛擬內存，143.8% CPU，系統完全卡死。

Issue 的作者直接點出罪魁禍首是 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 陣營最成功、也最具代表性的明星項目之一。過去幾年里，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 重寫一切。

“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++ 代碼打交道，文件系統、網絡、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 重寫軟件的大趨勢正在到來

如果說 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 需要幾天”。

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

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/

聲明：本文為 AI 前線原創，不代表平臺觀點，未經許可禁止轉載。

會議推薦

Agent 從 Demo 到工程化還差什么？安全與可信這道坎怎么過？研發體系不重構，還能撐多久？

AICon 上海站 2026，13 大重磅專題已上線，誠摯邀請你登臺分享實戰經驗。AICon 2026，期待與你同行。快來掃碼鎖定 8 折專屬席位或提交演講議題

今日薦文

你也「在看」嗎？