从 Anthropic 收购 Bun 谈起，聊聊 Bun 的败局

0. 引言

在几个月前，我对朋友说，

我很不喜欢 Bun 的一点是，除了网红营销，他还走了邪路，他为了提速：用了苹果的 JSCore，但是又为了兼容Node，又给 JSCore 打补丁兼容 V8，这不是邪路是什么，写到最后还有什么性能优势？

这句话是在我私人场合说的，确实比较尖锐，或者说，难听。但确实是我对 Bun 一系列路线的质疑。现在又听闻 Bun 被 Anthropic 收购的消息，我觉得有必要写一篇文章，聊聊我的一点看法。

1. 收购已经意味着 Bun 初心不再

公告¹上说，

Bun 仍然是开源并且以 MIT 许可证发布

Bun 仍然在积极维护中

Bun 仍然是核心团队主导开发

Bun 仍然在 GitHub 上公开构建

Bun 的路线图将继续专注于高性能的 JavaScript 工具、Node.js 兼容性以及取代 Node.js 作为 JavaScript 的默认服务器端运行时。

很熟悉的话术，对不对？只要是开源项目被收购，公告几乎都会有几句标准台词。然而呢？

各位读者如果对 Java 的国内生态比较熟的话，或许会知道 Hutool 的被收购事件，Hutool 被收购的时候公告也说不变，但我们从后续的报道来看，Hutool 终究还是变了。InfoQ 有篇文章叫，《Hutool 被卖半年多了，现状是逆袭还是沉寂？》，我觉得很能说明问题了。

从国外的消息来看，CentOS 先被红帽收购，我觉得红帽算保留了 CentOS 的初心，但后来红帽被 IBM 收购了，于是，CentOS 就只有 CentOS Stream 了。

Bun 的公告中，反复出现 “Claude”、“AI coding tools”

Bun 的头号“金主”和优先级已经锁死在 Claude 上了。公告里写得清清楚楚：

Anthropic is investing in Bun as the infrastructure powering Claude Code... If Bun breaks, Claude Code breaks¹.

这意味着 Bun 的开发资源将不再是为广大开发者服务，而是为了保证 Claude Code 的运行。我感觉 Hutool 被收购都没这么难看，至少那时候还没这么赤裸裸地把一个通用基础设施变成某个产品的附庸。

Bun 在公告里坦承

Today, Bun makes $0 in revenue.

也就意味着目前营收还是零。

又说，

...thanks to Anthropic, we can skip that chapter entirely and focus on building the best JavaScript tooling¹.

他们说加入 Anthropic 是为了“跳过”商业化探索的章节。

Bun 作者还说，

Our default answer was always some version of 'we'll eventually build a cloud hosting product.', vertically integrated with Bun’s runtime & bundler.

（我们的默认回答总是：我们将最终构建一个云托管产品，与 Bun 的运行时和打包器垂直整合。）

“做云服务”是几乎所有拿了风投的钱的开源工具面对盈利质疑时的万能挡箭牌，但对 Bun 来说，这根本行不通。况且，就算不被收购，做云服务和成为一个完善的基础设施本身也是矛盾的，因为作为商业产品总归要对你本身的业务服务，广大开发者的需求和业务哪个更重要？答案显而易见。

上面种种措辞实际上这就是 Bun 用被 Anthropic 收购“逃避商业化的探索”来包装自己的商业失败。给了你 4 年时间，拿了 2600 万美元融资，最后营收为零，无论是，他们本来就打算“成功退出”，还是确实没做到。这本身就是一种不可持续的证明。

我读书的时候成绩挺差的，我想，如果按照上面这种话术，我是不是可以说，为了专注于未来我得诺贝尔奖的伟大征程，我决定跳过这次期末考试？

现在大家都在说 AI 泡沫，连 Linus Torvalds 在 LinusTechTips 节目²里都说，

我完全不全相信当下围绕 AI 的那些炒作，我觉得现在的营销和市场都很病态扭曲。

当然不止他咯，不少投资人、开发者、普通用户对 AI 泡沫破裂是有隐忧的，把这样的一个重要的基础设施项目卖给一个 AI 公司，真的是一个好选择吗？假设，我说假设，近几年 AI 的发展如果不像炒作里说的那样，导致 Anthropic 的营收锐减，这个时候 Bun 会怎么样？再次被卖掉吗？还是直接被砍掉？

关于开源项目的运营，有个优等生，那就是 React。

React 对目前 Web 前端来说多重要不言而喻，它也是很优秀的基础设施项目。它曾经也由 Meta 负责开发和维护。

我记得在 10 月的时候，React 宣布成立基金会，由 Meta、Vercel、微软等公司共同参与。

一个优秀的开源的基础设施，最好的结局就是成立一个基金会。当然 React 本身也有反面例子。

众所周知，React 本身是用 Flow 写的。

Flow 在 JS 生态里面基本被 TypeScript 碾压，但这并不妨碍 React 源码在目前（2025/12）依然死守 Flow。为什么？因为对于 Meta 来说，React 首先是服务于 Facebook 主站的工具，其次才是开源项目。@types/react 到现在都是一个社区用爱发电的项目，和源码并不一定完全同步。

这是基础设施被大公司控制的代价：当社区利益和公司内部利益冲突时，公司永远选择自己。今年微软强化了对 VSCode 官方 C/C++ 插件的限制，直接阻碍了 Cursor 这样基于 VSCodium 的项目使用它，迫使社区寻求替代方案。当基础工具由商业公司主导后，为自家生态利益而做出限制并非危言耸听。

公告说，他们希望 Bun 与 Claude 的关系像“V8 与 Chrome”的关系，但这能一样吗？V8 从始至终都是 Google 开发的，Bun 可不是。而且，V8 的后面是 Google 这个庞然大物。

2. Bun、以及其他宣称要替代 Node.js 的，真的解决了 Node.js 的痛点吗？

答案是没有。

我们先聊一聊 Deno 吧，Deno 的发起人兼 Node.js 的创始人 Ryan Dahl。

Deno 发布的时候，抨击了 Node.js 哪些地方？我举几个例子。

1. 安全性差
2. 模块管理问题
3. 没有原生 TS 支持
4. 构建系统难用

我们一个个看。

1. 安全性问题，安全性方面，Node.js 20 引入了实验性的权限模型，虽然尚需完善，但这表明 Node.js 官方已经开始正视并着手解决这一痛点，不再是 Deno 的独占优势。

2. 模块问题，Node.js 现在已经原生支持 ES Module 了，而且 Node.js 23 开始，CommonJS 和 ESM 互操作问题基本算是彻底缓解了。

3. Node.js 如今也初步支持了 TypeScript， Node.js 在 22.18 之后，已经对使用可擦除语法的 TypeScript 模块增加了直接运行的初步支持（并且去掉了实验性标记）。况且 TS 还增加了 erasableSyntaxOnly 选项，更方便了可擦除语法的使用。

4. GYP 是挺难用的，但是 N-API 预编译的出现缓解了 node-gyp 带来的痛苦，而且，Node.js 现在也已经原生支持 WASM，你用 Rust/C++ 编译成 .wasm 文件，Node.js 直接加载运行。对于纯计算逻辑的库，WASM 正在逐渐取代传统的 C++ 扩展。

我们再看看 Bun，Bun 卖点是性能，诚然，Node.js 性能不太理想，可是我们看见：

1. 从 Node.js 20 开始，核心的 WHATWG URL 解析器改为使用高性能的 C++ 实现。
2. URL 模块只是 Node.js 性能演进的冰山一角。近几年的主线版本（例如 Node.js 20、22）持续通过升级 V8 和调整内部参数来挖掘性能潜力：Node.js 22 搭载的 V8 12.4 引入了更先进的 JIT 与 GC 策略，并默认启用 Maglev 编译器，专门优化短生命周期 CLI 程序的执行效率。

Bun 还有个卖点：一体化，关于 Bun 的一体化和 Node.js 后续原生功能的增强，我们后面来讲。

作为脚本语言，JavaScript 性能是不理想，但是，号称性能更好的 JSCore 和 Bun，难道会像用 SWC 取代 Babel 进行转译那样，得到质的提升吗？答案是否定的（况且 SWC 虽然性能上完全碾压 Babel，但是仍然不能完全代替 Babel 生态位，详见我另一篇文章），更何况，JSCore 只是冷启动上有优势，长期运行的服务端应用，V8 的优化其实更好。

这也是为什么许多长期运行的 Node.js 服务，在稳定运行数小时甚至数天后，其吞吐和延迟表现并不输给 Bun 搭配 JSCore 的组合。用更直白的话说：Bun 在 CLI/脚本层面可以吃到一大块冷启动红利，但在真正的后端服务里，那些红利会被 Node.js 的“长期调优”慢追平。

我们可以大方地承认，Deno 和 Bun 的出现，确实让 Node.js 团队感受到了压力，促进了他们的自我革新。但是，从现实来看，Deno 和 Bun 无法革了 Node.js 的命。站在 Deno 和 Bun 发布多年后的今天，Node.js 已经解决了它们当初抨击的那些问题，剩下的问题，要么 Bun、Deno 没有根本解决，要么，这些问题其实无关痛痒。

2.1 对 Bun 网红路线的看法

我们要批判 Bun 这种网红式的营销做法，这就和我们这几年见到的各种网红餐饮是一样的，刚开始的时候是爆火，排队排的老长了，结果过了一两年，还剩什么？Bun 这道爆款网红酸菜鱼是发布了很久，但我认为，最终可能还是会和网红餐饮差不多，昙花一现。

3. 技术路线是一条“邪路”

Bun 使用了 Zig 语言编写，还用了苹果的 JSCore 引擎。

为了兼容 Node.js，除了要通过适配器兼容各种 Node.js 的 API。Bun 不得不在 JSC 上模拟 V8 的行为。相当于造了一个“伪的 V8”。

我在国外旅游的时候见到的一些雕像，以及现在的一些仿真机器人，总给我一种诡异的感觉，其实计算机世界也有这样的恐怖谷效应。可能 99% 的情形下，Node.js 的兼容性没有问题，但是，一旦出现了剩下的关键 1%，就会导致诡异难查的 bug。而且，通过补齐 JSCore 和 V8 差异本身也会带来性能损耗。

Matteo Collina（Node.js 的开发者之一），就曾经遇到过这种情况：

I really like what @jarredsumner is doing with Bun, but I'm a bit frustrated by their compatibility claim with @nodejs. It's not fully compatible, and many inner details are different. This results in many random issues over my repos asking for fixes for Bun incompatibilities, while people try it out.

既然目标是替代 Node.js，为什么不直接沿用 V8 引擎以确保原生兼容？ Bun 为了那一点点冷启动优势而舍弃 V8，换来的却是一连串兼容性负担和开发者困扰，实在是得不偿失。可以说，它们在技术决策上就是为了标新立异而标新立异。在这种情况下宣称的性能提升有意义吗？

再聊聊 Zig。

回头看编程语言和运行时领域的历史，其实马太效应很显著。

根据 Stack Overflow 在今（2025）年的报告³，Zig 市占率是 2.1%。它也尚未发布 1.0 版本。同样是新生代语言，Rust 已经是 14.8%³，排行仅次于 Go。Zig 的爱好者们和 Rust 爱好者一样宣称要取代 C/C++ 的生态位，但这条赛道上只能有一个赢家，Rust 靠着社区和大公司的背书已经在稳步前进，剩下的只能被残酷地淘汰。

市场确实会让被广泛使用的语言，凡有的，还要给他，使他富足；但是对于被边缘化的语言，凡没有的，连他所有的，也要由他夺去。

上一个被这句话诅咒的语言是 Ruby，现在 Ruby 怎么样呢？Ruby 还是在曾经被大规模使用的情况下，才拿到 6.4% 这个份额，Zig 呢？

知乎上说，或许，Bun 是 Zig 生态里面为了一碟醋包的一桌饺子，看来真是。

4. 一体化在 JS 生态真的需要吗

笔者现在在做 Go 开发，Go 工具链是一体化的，它自带包管理、代码质量检查、格式化、编译、测试功能。我记得 .NET 和 Rust 也是。

那么，JavaScript 能不能这样的？不可否认的是这个愿景看起来是美好的。

JavaScript 生态去中心化很严重。微软、Google 和 Rust 基金会能够主导他们各自编程语言生态的发展，它们的一体化工具链是官方开发和推动的。但是 JavaScript 生态中并没有一个统一的领导者。

我们从 JavaScript 生态的发展来看，就是靠多种多样的开源项目各司其职。一个语言生态的发展是有很强的惯性的，JavaScript 当然不例外。

Rome 项目还记得吗？Rome 项目当年雄心勃勃，试图打造一个集解析、转译、测试、格式化于一体的 JavaScript 工具链，结果怎么样？在 2023 年的时候，宣布不再维护。Rome 项目留下了很好的遗产 Biome —— 但是 Biome 之所以在今天能够被认可，是因为它目前只专注于做 ESLint、Prettier 的平替，而不是试图一口气做完所有事情。前端生态中一个工具的成功，靠的就是“专注而高质量”。

OXC 项目也在做同样的事情，虽然 OXC 借助于 Vite 生态可以做得更好一些，但长期来看我并不是很看好，我只能说未来 OXC 怎么样我会慢慢观察。当然这个和本话题无关，就不多说了。

Bun 其实比 Rome、OXC 更激进，它试图一口气把运行时、转译器、打包器都做了，自带了前端才需要的文件系统路由⁴、还内置了对于 MySQL⁵、Redis 和 S3 支持。这战线拉得也太长了。

我们可以说，Rome 和 OXC，它们的一体化还有一定道理的，毕竟都是围绕着代码的解析、转译、打包这些事情展开的，毕竟这些事情是紧密相关的。

但是 Bun 呢？运行时和 Redis、S3 这些东西有什么关系吗？不同领域的既要又要，就像库克在评价二合一平板时说的，

你可以把烤面包机跟冰箱合并在一起，但这些事情并不会取悦你的客户。

术业有专攻。Bun 起初作为一个创业公司的项目，它也没有足够的能力把各方面做好。在 Bun 收购之前，我就在私底下场合对人说，一体化思路看起来是美好的，但是，我认为除非有微软、Google 这样的体量，否则在 JavaScript 生态中推行一体化不现实。

一体化在 JS 领域是一种高风险战略，看似减少了选择成本，实则让开发者丧失了按照自身项目特点挑选最佳工具的自由。更糟糕的是，从 JS 的特性来看，一体化产品一旦某一部分不符合需求，整个链条都无从替换，这与当今追求灵活可插拔的工程理念相悖。哪怕是 Go，都有不少人选择使用第三方工具来替换官方提供的内建工具，更何况，Bun 这个并不能主导 JS 生态的工具。

有人会问，根据更新日志 Node.js 在新版内建了 SQLite⁶、甚至是测试框架（node:test），你怎么说？

我觉得 Node.js 这样做和 Bun 是不一样的。

要透过现象看本质。猫和狗都可以有立着的耳朵和尾巴，难道是一种生物吗？它们连科、属都不一样。

你看，我在前面的文字中并没有对 Bun 内置测试框架和 SQLite 提出批评。

这两块是大部分“语言运行时/标准库早就习惯性带的东西”，Node.js 只是到现在才补齐，难道我跑个 demo 还要手动 npm i jest sqlite 吗？JavaScript 生态是要靠多元化，但是，这不能去往钻牛角尖的方向去解释。有些东西开箱即用是有必要。

但是打包器、路由、Redis、S3 不是，这是属于应用层面的东西。文件系统路由的集成我认为更离谱，如果说，Redis、SQL、S3 还是为运行时的后端应用服务的话，文件系统路由明显是为前端框架服务的东西，把它内建在运行时里，完全是割裂的。

这里可以给出一个更工程化的划分标准：

1. 如果某个能力在绝大多数后端项目中都必然存在，且与业务领域无关，比如：测试框架、基础数据库访问（如 SQLite，用于轻量持久化）、日志、配置等，把它们纳入语言运行时或标准库，是能带来更一致的开发体验。
2. 诸如前端文件系统路由、特定云厂商风格的对象存储 API、特定中间件（Redis 等），则更接近于具体技术栈和部署环境的选择，强行内建到运行时，会让运行时背负过多的技术路线押注，降低了整个生态的可插拔性。
3. 从这个角度看，Node.js 内建 SQLite 与 node:test，更多是在补齐“迟到的基础设施”，而 Bun 在运行时层面直接内建路由、Redis、S3，则是在把运行时推向一个特定的“云服务栈模版”，这两者的出发点并不相同。

我们可以理解 Bun 团队“想做云服务”盈利的想法，但是这些东西完全可以通过插件化的方式来实现，而不是内建在运行时里。

5. 结语

写到这里我也是感慨万千，我写了几段话之后又删掉了。这篇文章的结语比前面的章节要难写的多。

回头看 Bun 的这段路，其实很像这个时代很多闪亮却短命的技术故事：一开始以“要取代 XX”为口号，迅速吸睛，吸到钱，也吸到大量开发者的试用关注；但当热度退去，真正要走进长期、稳定、可持续的基础设施轨道时，却发现自己既没有足够清晰的定位，也没有一条务实的演进路线，最终只能把自己打包卖给一家更大的公司，用“加入生态”“跳过商业化探索”来粉饰落地失败的尴尬。

Bun 的败局，不只是某个项目经营层面的成败，而是给所有被“新一代XXX”这些词语打动过的人提了个醒： 基础设施的价值，最终是由可靠性、兼容性、可预期性和社区治理结构决定的，而不是几张漂亮的跑分（A 10x faster than B）、自媒体的“天哪，Node.js 已经沦为第二！”“我已经把我的前端工具链都换成 Bun 了！”、哪家独角兽公司的背书。

今天我们看到的，是 Bun 从“要当新基础设施”退居为“Claude 的一块基础设施”；明天或许还会有新的 Bun 出现，这个 Bun 不止是编程领域，更多领域也会有类似的故事上演。

一个生态的未来，从来不是靠一个“网红运行时”决定的，而是靠无数日常里缓慢而坚持的工程取舍堆积出来的。Bun 的故事到这里差不多落幕了，但我们该警惕的，并不是 Bun 本身，而是让 Bun 这一路走到今天的那套叙事逻辑。

6. 参考资料

Footnotes

1. Bun is joining Anthropic, Jarred Sumner, bun.com/blog/bun-jo… ↩ ↩² ↩³

2. B 站有授权翻译的视频，详见 www.bilibili.com/video/BV1ue… ↩

3. Technology, Stack Overflow, survey.stackoverflow.co/2025/techno… ↩ ↩²

4. File System Router, Bun 官方文档, bun.com/docs/runtim… ↩

5. SQL, Bun 官方文档, bun.com/docs/runtim… ↩

6. SQLite, Node.js 官方文档, nodejs.org/api/sqlite.… ↩