12 月 2 日，Anthropic 宣布收购 Bun。消息出来那天群里第一反应是「一家做大模型的公司，买一个 JavaScript 运行时干什么」，第二反应是「Bun 会不会闭源」。这两个问题背后其实是同一件事，工具链正在变成 AI 编码产品的竞争力来源。
这篇不打算复述新闻。我想把三件事讲清楚，Bun 到底快在哪、Anthropic 花钱买的是什么、以及作为一个还在用 Node 的前端，这件事之后你的技术选型要不要改。交易价格没有公开，但双方明确表示 Bun 将保持 MIT 开源协议，继续在 GitHub 公开开发，这是判断后面所有问题的前提。
在本篇文章中，我们将从浅入深，和大家一起学习以下知识：
- Bun 的来历、时间线和它在生态里的实际位置
- 用 JavaScriptCore 而不是 V8，这个选择带来了什么
- Anthropic 收购它的真实动机，Claude Code 在其中扮演什么角色
- 创始人为什么接受收购，开源承诺的可信度有多高
- 开发者最关心的三个问题的答案
- AI 编码场景为什么对工具链性能格外敏感
- 现阶段我对 Bun 的选型判断，哪些场景可以上，哪些还是先别动
一、Bun 是什么，它快在哪
如果你还没用过 Bun，这里简单介绍一下。
Bun 是 Jarred Sumner 在 2020 年前后开始构建的 JavaScript 运行时，起因很朴素。他当时在做一个类似 Minecraft 的体素游戏，Next.js 的热更新要等 45 秒，实在太慢了，于是动手写一个更快的工具。野心倒是从一开始就很大，目标是成为 Node.js 的有力替代方案。
它不只是个运行时。包管理器、打包工具、测试框架都集成在同一个二进制文件里，覆盖了前端开发工具链的各个环节。这是理解 Bun 的关键，它不是「另一个 Node」，而是把 Node 加 npm 加 Webpack 加 Jest 这一整套压缩成了一个可执行文件。
技术选型上，Bun 用的是苹果的 JavaScriptCore 引擎，也就是 Safari 那个，而不是 Node.js 和 Deno 都选的 V8。这个决定影响很深。JavaScriptCore 在冷启动和内存占用上有优势，进程起得快、常驻内存小。对于一个可能一秒钟被调用几十次的 CLI 工具来说，启动时间比长时间运行后的峰值性能重要得多。
那为什么大家不早点这么干呢。因为 Node 二十多年积累下来的生态是绑在 V8 上的，大量原生模块、调试工具、性能分析器都默认 V8 的行为。换引擎意味着这些东西要重新对齐，Bun 花了好几年做 Node.js 兼容层，就是在还这笔债。
时间线上，Bun v0.1 在 2022 年 7 月发布，v1.0 在 2023 年 9 月正式推出，之后逐步补齐了 Windows 支持和 Node.js 兼容性。到 2025 年 10 月，月下载量已经突破 720 万，GitHub 上有超过八万星，X 和 Midjourney 这样的公司在生产环境用它，Tailwind 的独立 CLI 也是用 Bun 构建的。
从一个人因为热更新太慢而开始写的玩具，到被科技公司收购，中间不到六年。
除了引擎选择，Bun 的性能还来自另外两个层面。一个是把功能整合进单一二进制，减少了进程间通信和文件 I/O 的往返。传统方案里你跑一次测试要经过 node 启动、模块解析、jest 加载配置、babel 转译几道，每道都有独立的进程开销。另一个是它大量用 Zig 写底层实现，文件系统操作、模块解析这些热路径没有走 JS 层。
包管理这块的提速最直观。bun install 的速度优势在原文和官方数据里都被反复提到，量级是比 npm 快 10 倍以上。这个数字我没在自己的项目上系统跑过基准测试，只在几个小 demo 里对比过体感，确实是「还没反应过来就装完了」的程度。锁文件格式这两年也在变，早期是二进制的 bun.lockb，后来官方转向了可读的文本格式，如果你在老项目上升级 Bun，这块要留意一下差异。
二、Anthropic 为什么要收购 Bun
Anthropic 的首席产品官 Mike Krieger 在公告里给出的理由很直接，Claude Code 需要更快的基础设施。
Claude Code 是 Anthropic 的 AI 编码工具，它本身就是用 Bun 构建，并且作为 Bun 可执行文件分发给数百万用户的。官方数据显示它在正式发布 6 个月后达到了接近十亿美元的年化收入。这个增长速度背后是海量的代码生成、测试、打包请求，每一毫秒的性能提升都会被用户规模放大。
先说结论，Anthropic 买的不是一个运行时，是对整条工具链的控制权。
顺着这个思路看就清楚了。Claude Code 这类产品的交付形态是 CLI，用户装完就要能跑，不能要求人家先装 Node 再装依赖。Bun 的单文件可执行程序特性正好解决这件事，bun build --compile 可以把任何 JavaScript 项目编译成一个自包含的二进制，用户机器上没有 Bun 也没有 Node 照样能跑，启动快，分发也简单。Claude Code、FactoryAI、OpenCode 这些产品都在用 Bun 构建自己的 CLI 和 Agent。
当分发形态是二进制的时候，运行时的启动速度就直接等于用户感知到的响应速度。一个每次调用要花 300 毫秒启动的工具和一个花 30 毫秒的工具，在交互式场景里是两个体验。
Mike Krieger 的说法是，当 AI 编码工具快速增长时，你需要能跟上节奏的基础设施，而 Bun 团队证明了他们有能力构建这样的基础设施。
我一直觉得这类收购最值钱的部分是团队而不是代码。Bun 的代码是 MIT 的，谁都能 fork，但能持续把一个 Zig 写的运行时推到生产可用、还能同时维护 Node 兼容层的团队，市面上找不出几个。
三、创始人怎么说，开源承诺可信吗
Jarred Sumner 在 Bun 官方博客发了一篇长文解释为什么接受收购。核心观点归纳成一句话，与其让 Bun 成为一家挣扎着找商业模式的创业公司，不如专注做好工具本身。
他写道：
「今天，Bun 的收入是 0 美元……与其让我们的用户和社区经历『Bun 这家 VC 支持的创业公司试图摸索变现模式』的阶段，感谢 Anthropic，我们可以完全跳过那一章，专注于打造优秀的 JavaScript 工具。」
这段话很坦诚，也说中了开源项目最难的地方。走商业化路线容易伤到开源的纯粹性，社区一有风吹草动就开始担心哪天核心功能被划进企业版；靠捐赠和志愿者又撑不起长期的全职投入，Bun 这种量级的项目不是业余时间能维护的。Anthropic 的收购给了第三条路，团队拿到长期资金，不需要向用户收费，也不需要改开源协议。
Sumner 还透露了收购后的三个方向。让 Claude Code 和 Claude Agent SDK 运行更高效，Bun 会针对 AI 编码场景做优化；更早洞察 AI 编码工具的发展方向，作为内部工具的提供方，Bun 团队能提前知道需求；更快发布新功能，有了稳定资金和明确的应用场景，开发节奏会加快。
那这个开源承诺到底该信几分。我的看法是可以信，但理由不是「他们承诺了」，而是「闭源对 Anthropic 没好处」。Bun 的价值有相当一部分来自社区贡献的 Node 兼容性修复和 bug 报告，闭源等于把这部分白干的劳动力赶走，然后自己雇人补上。这笔账怎么算都不划算。
历史上有过类似的关系。Google 和 V8、苹果和 JavaScriptCore，都是公司出钱养引擎，但引擎本身开源、被整个生态使用。这种模式已经跑了十几年。
四、开发者最关心的三个问题
1. Bun 还会开源吗
会。Bun 继续保持 MIT 协议，开发工作依然在 GitHub 公开进行，原团队继续维护，这几点在公告里被反复强调。
MIT 这一点比承诺本身更有保障。即便未来真的转向，已经发布的版本仍然是 MIT 的，社区可以从那个点 fork 出去。这是许可证给你的底牌，跟公司的意愿无关。
2. Bun 会变成 Anthropic 专属工具吗
目前看不会。Bun 的路线图依然围绕三个目标，高性能、Node.js 兼容性、成为 Node.js 的直接替代品。这三条对整个 JS 生态都有价值，不是只服务 Claude Code。
Sumner 也明确说了会针对 Claude Code 做优化，但这不等于放弃通用性。AI 编码工具需要的东西，更快的启动、更低的内存占用、更快的依赖安装，恰好和普通开发者要的是同一批。这就是这次收购里最幸运的地方，双方的需求方向是重合的，而不是冲突的。
真正需要观察的是优先级。当社区的需求和 Claude Code 的需求发生冲突时，issue 队列会怎么排。这个要看后面一两年的实际表现，现在下结论太早。
3. 现在开始用 Bun 还安全吗
从项目持续性看是变好了。有了长期资金保障和明确的应用场景，比起靠捐赠维持的开源项目，Bun 的未来反而更确定。以前劝人别用新工具的理由通常是「万一作者不维护了呢」，这条理由现在基本站不住。
从技术成熟度看要分场景，这个下面第六节展开说。
五、AI 编码工具为什么对工具链性能这么敏感
这个问题背后有个更大的变化。
传统开发模式下，工具链慢一点不算致命。npm install 要三分钟，你可以去泡杯咖啡；构建要五分钟，反正提了 PR 也要等人 review。人的思考时间远远大于机器的等待时间，工具链的性能被人的节奏掩盖掉了。
AI 编码工具把这个前提打破了。Claude Code 这类产品，用户期待的是秒级反馈，描述需求、生成代码、立刻看到运行结果。这条链路上的每一步都要快，代码生成要快、依赖安装要快、构建打包要快、测试执行要快。任何一环卡住，整个交互体验就断了。
更关键的是量级变了。人一天可能跑十次构建，AI 可能一分钟内生成几十个候选版本，每个都要走完整的工具链验证。原本可以忽略的固定开销，乘以几十倍之后就变成了主要成本。
所以这不是「快一点更好」的问题，是「不够快就做不成」的问题。
Bun 恰好解决了代码生成之后的三个环节。包管理器比 npm 快一个量级，内置打包工具比 Webpack 快出几倍，测试运行器的启动时间极短。这些优势在人类开发者身上体现为「体验不错」，在 AI 编码场景下就会被放大成实实在在的产品差异。
这件事也不只是 Anthropic 的需求。GitHub Copilot、Cursor、Replit 这些产品都会撞上同一堵墙。想深入了解 Claude 这套工具体系是怎么组织能力的，可以顺带看看我写的 Claude Skills 如何将提示词升级为可复用技能。
六、这次收购给 JS 生态留下的三个信号
第一个信号是高性能工具链的价值被主流认可了。Bun 用不到三年时间从实验性项目长成被收购的战略资产，证明开发者对工具性能的需求是真实且迫切的。过去几年 esbuild、SWC、Vite、Turbopack 这一波原生语言重写的浪潮，方向是同一个。
第二个信号是 AI 公司开始向下游延伸。Anthropic 本可以只做模型和应用层，但它选择买下底层工具链。这说明要提供差异化的编码体验，光有模型不够，得能控制整个执行栈才能做到极致优化。类似的动作后面大概率还会有。
第三个信号是开源项目的可持续性有了新范式。保持开源、服务社区，通过被战略买家收购解决资金问题，这条路径对其他高质量开源项目是个参考。它比「开源核心加企业版」的模式对用户更友好，前提是买家自己有足够大的商业模式来消化成本。
三个信号指向同一个判断，工具链不再是「随便选一个能用就行」的领域了。
七、我现在的选型判断
回到最实际的问题，你的项目该不该换 Bun。
我自己的分法是按风险敞口来。开发期的辅助工具用 Bun，问题不大，改回去的成本几乎为零。bun install 装依赖、bun run 跑脚本、CI 里做依赖安装，这几个场景出问题最多是回退到 npm 重跑一次，不影响线上。写内部 CLI 工具的话 bun build --compile 也很香，分发一个二进制比让同事装 Node 环境省事太多。
生产运行时这块我会保守一些。不是说 Bun 不行，而是 Node 二十年积累的排查手段、APM 接入、内存快照工具、线上问题的搜索结果数量，都是隐形的保障。真出了事，Bun 相关的踩坑记录还是明显少于 Node。这个差距会缩小，但现在还在。
几个具体的判断点。
用了较多原生模块（node-gyp 编译那类）的项目，先在 CI 上完整验证一遍再说，兼容层能覆盖大部分但不是全部。用了 Next.js 这类重框架的，看框架官方对 Bun 的支持声明，别自己硬凑。团队里没人有余力排查运行时层面的怪问题的，也建议先别动生产。
反过来，纯 TypeScript 的后端服务、脚本工具、Monorepo 里的构建任务，这些换起来收益明显且回退容易，可以先拿它们试水。
这块我只在自己的小项目和 demo 上验证过，没有大流量线上环境的数据支撑，你要是有更大规模的实践结论，欢迎在评论区纠正我。
总结
这次收购里真正值得记住的信息其实不多。Bun 保持 MIT 开源，团队继续维护，路线图没有偏离 Node.js 兼容这个核心目标，这三条决定了对普通开发者来说风险是下降的而不是上升的。
Anthropic 花钱买的是执行栈的控制权。AI 编码工具把工具链性能从「体验加分项」变成了「产品必要条件」，这个变化会持续往下游传导，后面类似的整合大概率还会出现。
对你个人的选型来说，我的建议是先在低风险场景用起来，开发期工具、CI、内部 CLI 这几块收益立竿见影，回退成本又低。生产运行时可以再观察一段时间，等你的技术栈里有人踩过坑并且写出来了，再动不迟。
工具链在进化，但换工具这件事本身不该赌运气。
