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。
