Bun 眼下没有变差。
它仍然快，TypeScript 支持顺手，测试、打包、包管理能少装一批依赖。对很多 JavaScript/TypeScript 项目来说，Bun 依然是少数能让人认真考虑迁移的工具。
反常点在这里：真正被质疑的不是 Bun 的代码，而是它的新归宿。
Anthropic 在 2025 年 12 月收购 Bun 时承诺，Bun 继续开源，继续采用 MIT 许可，原团队和路线图延续。按理说，这是一组很强的安抚信号。但几个月后，Claude Code 的产品体验、计费和限制策略出问题，开发者开始重新问一个更现实的问题：Anthropic 还适合长期托管 Bun 吗？
这篇文章判断的不是“Bun 现在能不能用”。答案很明确：能，而且仍然优秀。
我更在意的是另一件事：基础工具链最怕规则不稳。运行时、包管理器、测试工具一旦进了项目脚手架，后续每一次 CI、每一次新人接手、每一次故障排查，都会继承这个选择。
Bun 没失分，失分的是所有权带来的不确定性
Anthropic 收购 Bun 时，至少给了三个承诺：开源不变，MIT 许可不变，原团队和高性能 JavaScript 工具路线不变。
目前没有证据显示这些承诺已经破裂。不能把这件事写成“Bun 要闭源了”，也不能推断团队被裁撤或路线被砍。材料不支持。
更微妙的是，Anthropic 维护 Bun 还有一个正向激励：Claude Code 依赖 Bun，可执行文件也和 Bun 有关系。如果 Bun 出问题，Claude Code 的交付也会受影响。一个被核心产品用到的基础工具，通常不会被轻易丢在角落。
问题是，这个逻辑有前提：Claude Code 自己得证明 Anthropic 懂开发者工具。
现在这个前提变弱了。
| 事项 | 目前能确定的事实 | 对开发者的含义 |
|---|---|---|
| Bun 被收购 | Anthropic 于 2025 年 12 月收购 Bun，并承诺开源、MIT 许可、原团队和路线图延续 | 不能据此判断 Bun 已经变差 |
| Claude Code 依赖 Bun | Bun 对 Claude Code 的交付有正向价值 | Anthropic 有维护 Bun 的现实动机 |
| Claude Code 4 月事件 | 官方 postmortem 提到默认推理强度降低、旧会话 bug、提示词改动影响编码质量 | 问题更像产品治理和发布控制，不只是模型能力 |
| OpenClaw 争议 | 报道称第三方 harness 可能额外收费，git 历史中相关文本也可能触发拒绝或计费 | 工具行为变得难预测，影响团队采用信心 |
这张表里的重点，不是把 Bun 和 Claude Code 强行绑成一个命运共同体。
重点是，开发者买账的不只是性能。还包括规则稳定、故障可解释、价格可预期。恰恰是这些东西，Claude Code 最近没有给出足够好的示范。
对技术负责人来说，影响很具体。
如果团队正在评估 Bun 作为新项目默认工具链，采购或技术选型可以慢半拍。不是否决 Bun，而是把 Anthropic 的产品治理风险写进评估表。尤其是那些计划把 runtime、test、bundler、package manager 一起切到 Bun 的团队，更应该多留一条回滚路径。
Claude Code 的下滑，让“Anthropic 会照顾好 Bun”没那么好信
Claude Code 曾经是 AI 编码代理里很强的样板。
它能读项目、改代码、运行命令、修错误。对开发者来说，它不是单纯补全，而是试图接管一段完整工作流。这也是很多人愿意把它当成 Anthropic 产品能力样本的原因。
但 4 月的官方 postmortem 至少承认了几类问题：默认推理强度降低，旧会话 bug，提示词改动影响编码质量。
这些问题放在普通聊天产品里，可能只是体验波动。放在编码工具里，性质更重。因为开发者依赖的是可重复性：同一个项目、同一类任务、同样的权限边界，工具最好不要今天像队友，明天像陌生人。
模型强，不等于产品强。
编码工具的日常体验，取决于上下文管理、权限边界、计费规则、失败时的解释。Claude Code 的争议正好集中在这些地方。
OpenClaw 争议更伤信任。
据 TechCrunch 报道，Claude Code 订阅用户使用 OpenClaw 等第三方 harness 可能需要额外付费。Gigazine 后续报道还提到，git 历史中出现 OpenClaw 相关文本，可能导致请求被拒或额外计费。
这里要留一个限制：这些策略背后可能有反滥用、商业授权或成本控制考虑。企业不是不能管成本，也不是不能限制第三方接入。
但开发者面对的是结果。
如果一个工具会因为第三方 harness、仓库历史文本或上下文残留，触发拒绝或额外计费，那它就很难被当成稳定基础设施。尤其在团队环境里，没人愿意为了一个看不见的规则，反复解释账单和失败原因。
这也是 Bun 被波及的地方。
不是 Bun 的性能突然不行了，而是 Anthropic 的产品治理样本变差了。信任一家公司托管基础工具，本来靠长期行为积累。Claude Code 的问题让这笔信用开始打折。
短期不用逃离 Bun，但要把选择拆开
最容易犯的错，是把这件事写成站队：要么继续信 Bun，要么立刻迁走。
现实没这么简单。
Bun 和 pnpm 不是同一类东西。pnpm 主要是包管理器。Bun 覆盖运行时、包管理、测试、打包和 TypeScript 执行。把日常包管理切回 pnpm，不等于 pnpm 能替代 Bun，更不等于它能替代 Node.js。
更稳妥的做法，是按场景拆。
| 场景 | 更现实的动作 | 原因 |
|---|---|---|
| 只需要包管理、monorepo、较好的磁盘占用 | 可以优先用 pnpm，或把 Bun 暂缓为默认选择 | 切换成本低，收益明确，风险更可控 |
| 已深度使用 Bun runtime、bun:test、内置打包 | 不建议因担忧立刻迁移 | CI、脚本、兼容性测试都有成本 |
| 新项目准备全栈押注 Bun | 建议保留回滚方案，先验证关键依赖和部署链路 | 风险不在当前性能，而在长期规则稳定性 |
| 团队正在采购 Claude Code 或接入 AI 编码工具 | 延后大规模铺开，先小范围试点 | 计费、限制和行为可解释性仍需验证 |
这也是我对原始担忧更认可的地方：它不是说 Bun 已经坏了，而是提醒大家别只看 benchmark。
快当然重要。但基础工具的账，不只算安装速度。还要算迁移成本、锁定成本、规则变化成本。
对个人开发者，短期把日常包管理转向 pnpm，是一种低成本避险。对团队项目，尤其是已经跑在 Bun 上的项目，马上迁移反而可能制造更多问题。
真正该看的，是三个变量。
第一，Bun 的 release 节奏是否保持。不是看口号，看版本更新、bug 修复和兼容性推进。
第二，Node.js 兼容路线是否继续往前走。Bun 的价值很大一部分来自“更快但不割裂”。如果兼容性停滞，迁移吸引力会下降。
第三，Anthropic 能不能把 Claude Code 的限制和计费规则讲清楚。开发者可以接受收费，也可以接受边界。不能接受的是边界漂移，且解释滞后。
回到开头，Bun 现在仍然好用。
但好用不等于可以无脑押注。Anthropic 收购 Bun 后，承诺还在，技术也还在。真正变贵的，是信任成本。
工具链选择从来不是求快一时。差之毫厘，谬以千里。对基础设施来说，最要命的往往不是慢一点，而是你不知道下一条规则会怎么变。