Bun 是个好软件。
我天天用它。它快，它实用，团队迭代速度惊人。用它写 TypeScript 脚本、跑测试、打包工具链，体验都很爽。这就是为什么我写这篇文章的时候特别难受——我真心希望 Bun 能赢，希望有一个真正能打的 Node.js 替代品，希望包安装更快、测试更快、打包更高效。
但现在我真的有点担心了。
发生了什么
2025 年 12 月，Anthropic 收购了 Bun。
官方公告里的话听起来都很美好：Bun 保持开源、保持 MIT 许可、团队继续做、路线图继续聚焦高性能 JavaScript 工具和 Node.js 兼容性。
还说了这句：
Claude Code 以 Bun 可执行文件的形式发送给数百万用户。如果 Bun 出了问题，Claude Code 就出问题。Anthropic 有直接的动力让 Bun 保持优秀。
当时听起来挺让人安心的。Anthropic 的核心产品构建在 Bun 之上，这意味着他们有直接利益驱动让 Bun 保持高速、稳定、优秀。我现在仍然认为这个逻辑有道理，但裂缝开始出现了。
Bun 仍然是一个优秀的 JavaScript 运行时，但它现在在一家看起来对软件本身并不那么上心的公司手里。
不是说模型不行
这不是一篇 "Anthropic 就是坏" 的文章。至少不完全是。我仍然认为 Anthropic 的模型很优秀。Claude Opus 仍然是最好的编程、写作、推理、通用开发模型家族之一。模型质量不是我的关注点。
我的关注点是模型上面的产品层。
Claude Code 今天用起来有点糟糕。
Claude Code 曾经很棒
大概一年前，Claude Code 的体验是让人惊艳的。它是第一批让我相信开发者工作流会因此改变的工具之一。那时候它真的很聪明，能理解上下文，能处理复杂的多步骤任务，能帮你完成实际的编码工作。
然后它开始变慢了，开始出更多 bug，开始出现一些以前从来没有过的奇怪问题。
这和 Bun 有什么关系？
Bun 现在是 Claude Code 的运行时。如果 Bun 的质量下降，Claude Code 的质量也会下降。如果 Anthropic 开始把更多精力放在模型本身而不是配套工具链上，Bun 的维护质量可能会受影响。
我不是在说 Bun 现在有问题。我是在说这个收购案让我开始警惕一种可能性：一家公司收购了一个开源项目，然后用一种 "够用就行" 的态度对待它——这就是我们常说的 enshittification。
enshittification 是什么
Cory Doctorow 发明了这个词，用来描述平台软件质量逐渐下降的过程。
典型的路径是这样的：
- 公司先做出一个好产品，让用户依赖它
- 用户离不开之后，开始变现——提高价格、减少功能、降级服务质量
- 用户抱怨，但已经陷进去了，很难迁移
- 公司继续压缩成本，产品继续变差
这个模式在很多软件和服务上都见过。Twitter 变 X，Facebook 动态质量下降，各种 SaaS 工具悄悄涨价……
对于开源项目来说，被大公司收购往往是一个危险信号。除非大公司有直接的产品利益驱动继续维护它，否则往往会被边缘化，团队被裁撤，或者被束之高阁。
例子：npm 和 GitHub 的故事
其实我们见过类似的案例。
npm 被 GitHub 收购后，Node 生态的核心包管理器经历了一段混乱的时期。很长一段时间 npm 的 CLI 工具体验相当糟糕——慢、不可靠、有时候会莫名其妙失败。pnpm 和 yarn 的崛起某种程度上就是开发者对 npm 体验不满的结果。
GitHub 收购 npm 并不是因为他们想做一个更好的包管理器。他们想买的是 npm 这个 registry 的数据价值和生态影响力。CLI 工具的质量不是他们的核心关注点。
类似的故事还有不少。
不是说 Bun 一定会走向 enshittification
让我把话说清楚：我不是在断言 Bun 会变差。
事实上，Bun 团队仍然在活跃地提交代码，Bun 的性能仍然在提升，很多开发者仍然在用它并且喜欢它。
而且 Anthropic 确实有上文说的那个直接利益驱动——如果 Bun 出了问题，Claude Code 会出问题，这会直接影响他们的商业产品。这让 Bun 处于一个相对特殊的位置，不像那些纯粹被当作资产收购的开源项目。
我的担忧不是 "Bun 一定会变差"，而是 "这种担忧现在是合理的"。
开发者能做什么
作为开发者，我们可以做几件事：
1. 保持多运行时能力
不要把所有项目都绑死在 Bun 上。知道怎么用 Node.js 和 Deno，保持在不同运行时之间切换的能力。这样如果某个运行时开始变差，你可以相对平滑地迁移。
2. 关注开源项目的治理结构
收购不是终点。关注被收购后的开源项目是如何被维护的——团队还在吗？代码提交还活跃吗？文档还更新吗？这些问题比表面上的版本号更重要。
3. 参与社区，而不是只当消费者
开源项目的健康度很大程度上取决于社区参与。如果你依赖某个项目，考虑贡献代码、报告 bug、帮助文档翻译。一个活跃的社区是被收购后仍然保持高质量的重要保障。
结语
我用了很长时间才接受这个想法：好的软件不一定能一直好下去。
商业逻辑会变，优先级会调整，团队会换人。开源不是永恒的避风港，被大公司收购也不是成功的保证。
但这不是绝望的理由。这是保持警惕的理由。
Bun 现在仍然是最好的 JavaScript 运行时之一。TypeScript 支持很棒，NPM 兼容性很好，性能数据很亮眼。如果你在用一个技术栈，不要因为读了一篇文章就马上换掉它。
但要保持观察。
当一个工具变得足够重要的时候，关心它的走向就不是多余的。你越依赖一个东西，越要关注它的健康状况。这不是焦虑，这是工程师的基本素养。
我还是希望 Bun 能赢。希望它能打破 "好软件被收购后就会变差" 这个规律。希望 Anthropic 能证明我多虑了。
我真的很希望我是错的。
你怎么看这次收购？你认为 Bun 的未来会怎样？欢迎分享你的观点。