过去几年，Bun 一直是 JavaScript 生态里最会制造期待的项目之一。它想同时替代 Node.js 运行时、npm/yarn/pnpm 包管理器、Jest/Vitest 测试工具，以及一部分构建工具。它的卖点很明确：一个二进制，启动快，安装快，默认支持 TypeScript，开发体验足够爽。
Bun 原本也有一个很强的技术标签：它主要由 Zig 写成。这个标签后来成了故事的起点。2025 年 12 月 3 日，Anthropic 宣布收购 Bun，并把它描述为 Claude Code 基础设施的一部分，Bun 被认为能继续支撑 AI 编程工作流的速度和稳定性。
到了 2026 年 5 月，事情突然加速。5 月 5 日前后，Bun 仓库出现 Zig 到 Rust 的迁移指南和实验分支。作者 Jarred Sumner 的说法：这只是实验，尚未承诺重写，甚至"很大概率会全部丢掉"。但 5 月 14 日，PR #30412 被合并进 main：标题很直接，Rewrite Bun in Rust。
这个 PR 的规模足够吓人：GitHub 页面显示它把 6755 个 commits 从 claude/phase-a-port 分支合进 main。PR 描述称，Rust 版本通过了 Bun 既有测试套件，修复了若干内存泄漏和 flaky tests，二进制体积也有下降。但同一个描述也承认：进入非 canary 版本前还要做优化，后续还会有一系列清理 PR。
这就是争议的核心：一个 9 万多 star、被不少项目当作基础设施的运行时，能不能用如此激进的方式完成核心代码迁移。
官方的说法：Rust port 还没正式发布
5 月 21 日，Bun 官方发布了一份 unsafe 审计页面。页面开头写得很清楚：Rust port 尚未进入正式发布版本，你今天安装的 Bun 仍然跑的是原 Zig 实现。
但这份审计也确认了另一个事实：当时的 Rust port 有 13,365 个 unsafe blocks。官方的解释是，大部分来自 FFI 边界、从 Zig port 过来的 ownership idiom，以及少量性能路径；其中约 9,300 个可以转成 safe code，约 4,000 个会保留在必要边界上。
我之前也写过相关文章：
一个和 JavaScriptCore、libuv、mimalloc、uWebSockets 等 C/C++ 组件打交道的 runtime，不可能没有 unsafe。真正值得追问的是：这些边界是否被清晰隔离？哪些 invariant 由谁维护？后续修复是不是能被人类维护者理解？
社区的反应：这是一场信任危机
从公开信息看，Bun 团队给出的叙事变化非常快：先是"实验分支，可能会扔掉"，随后变成"PR 已合入 main，可以 canary 试用"。Heise 对此的概括很直接：5 月 14 日合并后，2,188 个文件发生变化，约一百万行被重写，约四千行被删除；社区问题包括测试被修改、unsafe 使用、以及新问题开始积累。
如果这是一个普通库，大家最多谨慎升级。但 Bun 是 runtime、包管理器、测试器和构建工具的集合。它处在开发链路的底层。底层工具一旦出问题，影响的是安装依赖、构建产物、执行脚本、CI、发布流程，以及安全边界。
这也是为什么这次争论很快从"代码质量"变成"是否还能信任"。
后续：一些项目开始限制、解耦或迁移
最明确的例子是 yt-dlp。5 月 20 日，yt-dlp 在 GitHub issue #16766 中宣布：Bun 作为 EJS 兼容 JavaScript runtime 的支持将被限制并弃用。它把支持范围限定到 Bun 1.2.11 到 1.3.14。理由有两层：一是早期 Bun 版本构建 EJS 时可能忽略 lockfile，结合近期 npm 供应链攻击背景被认为有安全风险；二是 Bun 最近用 Claude 重写成 Rust，维护者认为其开发方向有"fully vibe-coded"的趋势，因此把 1.3.14 设为上限，也就是原 Zig 代码库的最后版本。
另一个直接例子是 Electrobun。它原本就把 Bun 放在架构核心：官方文档写着 Electrobun app 本质上是一个 Bun app，主进程跑 Bun，并通过 Bun FFI 调用原生能力。5 月 23 日，Electrobun 作者 Yoav 在 X 上说，Electrobun 2.0 将因为 Rust rewrite 与 Bun 解耦。
除此之外，还有一些项目在近期移除 Bun 痕迹，但不一定和这次 AI 重构有关。
Sentry CLI 在 5 月 22 日合并了 PR #1002，标题是"remove Bun artifacts and convert remaining Bun APIs"。PR 正文写得很清楚：这是 Bun → Node.js 迁移的 Phase 5，移除 bun.lock、bunfig.toml、@types/bun，并把 Bun.spawn()、Bun.sleep() 改成 Node API。它确实是"剥离 Bun"，但 PR 本身没有说原因是 Bun Rust rewrite。
OpenTUI 在 5 月 6 日合并 PR #1027，移除 Bun-specific runtime dependencies，让 tree-sitter 子系统和 FFI loader 通过平台层适配 Node.js/Deno。它发生在 #30412 合并前，更像是项目主动做 runtime-agnostic，而不是被这次合并直接触发。
Variableland/dx 在 5 月 1 日也合并了从 Bun runtime 迁到 Node.js 的 PR。这同样早于 Rust rewrite 合并。
所以，准确说法应该是：这次 Bun AI 重写事件之后，至少 yt-dlp 和 Electrobun 给出了明确的限制/解耦回应；与此同时，GitHub 上确实能看到一批移除 Bun lockfile、Bun API、Bun runtime 依赖的项目，但这些迁移动机并不完全相同，不能都归因给同一个事件。
99.8% 测试通过，不等于 99.8% 信任
软件工程里，测试通过只说明代码通过了已经写出来的测试。它不能证明代码没有未覆盖路径，不能证明抽象边界清晰，也不能证明未来维护者能读懂。
这也是 AI 大规模改写基础设施时最容易被忽略的一点：AI 可以快速制造"行为相似"的代码，但基础设施项目需要的不只是行为相似。它还需要可解释的设计、可追踪的历史、可审查的变更，以及出现事故时能被人类快速定位的结构。
Bun 官方说 Rust port 修复了内存泄漏和 flaky tests，也说它会带来 compiler-assisted tools 来捕捉和预防内存 bug。这些都可能是真的。Rust 也确实能把很多问题提前暴露出来。但如果迁移方式让社区感到"没人真正读过这百万行"，那技术收益就会被信任成本抵消。
如果你的项目正在用 Bun，怎么判断？
首先，不要恐慌式删除。Bun 1.3.14 仍然是原 Zig 实现，官方也说 Rust port 还没进正式 release。你的项目如果只用 bun install 或 bun test，风险和用 Bun 作为生产 runtime 并不一样。
更理性的做法是把 Bun 的用途拆开看：
-
- 如果只是包管理器：关注 lockfile、CI 可复现性、供应链扫描和部署平台支持。
-
- 如果是测试运行器：确认测试语义和 Node/Vitest/Jest 的差异是否影响结果。
-
- 如果是生产 runtime：谨慎使用 Bun-only API，尤其是 FFI、HTTP server、数据库、子进程、文件系统这些靠近系统边界的能力。
-
- 如果你的工具要给外部用户安装：尽量不要把 Bun 作为唯一可用 runtime，至少提供 Node/Deno 路径。
在基础设施选型里，速度很重要，但可预测性更重要。你需要知道什么时候升级，怎么回滚，谁负责安全公告，谁会审查关键路径。
最后
这次事件后 Bun 仍然有真实价值，也有足够强的工程团队。Rust rewrite 也可能最终变成一个成功案例。
但它已经给所有开源基础设施项目提了一个醒：AI 可以加快迁移，不能替代信任建设。对底层工具来说，最贵的是让别人相信这段代码值得运行在自己的机器上。
资料来源
-
• Anthropic: Anthropic acquires Bun as Claude Code reaches $1B milestone
-
• Bun PR #30412: Rewrite Bun in Rust
-
• Bun: Bun's unreleased Rust port has 13,365 unsafe blocks. Most can be removed.
-
• The Register: Bun posts Rust porting guide, says rewrite is still half-baked
-
• Heise: AI Porting: Claude Rewrites Bun Codebase in Rust
-
• yt-dlp issue #16766: Bun support is now limited and deprecated
-
• Yoav / Electrobun: Electrobun 2.0 will be decoupled from Bun
-
• Sentry CLI PR #1002: remove Bun artifacts and convert remaining Bun APIs
-
• OpenTUI PR #1027: remove Bun-specific runtime dependencies
-
• Variableland/dx PR #168: remove Bun as runtime, migrate to Node.js