大家好，我是若风。
2025 年 12 月上旬，Bun 先宣布加入 Anthropic，随后 Anthropic 也发布公告：它收购了 Bun。
我也注意到，Bun 官方在加入 Anthropic 的文章里提到 Claude Code、Factory AI、OpenCode 等 AI 编程工具都在使用 Bun。换句话说，它已经不只是一个"开发者自己试试看"的运行时，也开始进入 AI coding 工具链的内部执行路径。
这 2 件事情叠加引起了我对 Bun 的好奇，说实话，我之前对 Bun 的印象一直停留在"又一个号称比 Node 快的 JS 运行时"这个层面。但这次收购让我觉得事情没那么简单------Anthropic 为什么要收一个 JavaScript 运行时？
带着这个疑问，我花了不少时间做了一次深度调研。越看越觉得，Bun 这个项目比我想象的有意思得多。它不只是"比 Node 快"，它其实在试图重新回答一个问题：现代 JavaScript 工程，到底应该由几层工具组成？
今天这篇文章，就是这次调研的结果。
先说结论
Bun 不是 React、Vue 那种"框架"，而是一个试图把 JavaScript 运行时、包管理器、测试运行器、Bundler、全栈开发服务器 压进同一个二进制里的基础设施产品。
用人话说：Bun 想把 "Node.js + npm/pnpm + Jest/Vitest + esbuild/Vite" 这一大串组合拳，收缩成一个叫 bun 的命令。
这个野心非常大。大到现在社区对 Bun 的态度非常分裂：一边是兴奋，因为确实快；另一边是警惕，因为边界扩得太宽，质量能不能跟上是个问号。
Bun 怎么来的：一次"忍不了"
Bun 的起点不是抽象的"想做一个更快的 JS 运行时"，而是非常具体的工程烦躁。
创建者 Jarred Sumner 在多次访谈和项目回顾里都把 Bun 的起点讲得很工程化：他当年在做一个浏览器里的 voxel game，代码库一大，开发服务器反馈变得难以忍受。InfoWorld 访谈里提到，从保存代码到浏览器看到变化大概要 30 秒；后来的复盘文章里也常把这个痛点描述成几十秒级的等待。不是哲学问题，是会把人耐心一点点磨掉的那种工程问题。
于是他先去折腾 JSX/TypeScript 转译器，后来为了让 Next.js 的服务端渲染跑起来，发现自己又不可避免地走进了 runtime 的坑里。
很多产品的诞生，表面上是"新需求催生新架构"，实际上更像"一个足够能折腾的人，被一个具体痛点逼进了深水区"。Bun 就是后者。
两个关键选择，决定了 Bun 的一切
Bun 在 2021 年做了两个技术选择，几乎锁死了它后来所有的优点和缺点。
选择一：用 Zig，不是 Rust
Jarred 说他一开始也考虑过 Rust，但最后选了 Zig。理由不是"生态更好"，而是更朴素的------他要对底层行为、内存和系统调用路径有足够直接的控制。
Bun 从第一天起就是一个极度强调性能路径的产品。语言选择不是外围决策，它会把团队的心智模型也一起定型。
选择二：JavaScriptCore，不是 V8
这一步影响更大。Node 和 Deno 背后都是 V8，Bun 反而绕到 Safari 那条线，嵌入 WebKit 的 JavaScriptCore。
为什么？因为 JavaScriptCore 的启动速度快。
这个选择给了 Bun 很强的启动速度优势，也让它从第一天就和 Node/Deno 拉开了技术路线差异。但代价也很明显：在 Node 兼容、V8 私有 C++ API、Windows 适配这几个方向，Bun 注定要比"直接站在 V8 上做演化"的路线更辛苦。
也就是说，Bun 后来的很多优点和很多麻烦，其实在 2021 年这两个选择里就已经埋下了。
Bun 的版本演化：从"能跑 demo"到"被 Anthropic 收购"
Bun 到今天大致经历了四个阶段，每个阶段的核心矛盾都不一样。
第一阶段：萌芽期（2021-2022.7）
核心矛盾：如何把对 JavaScript 工具链低效的个人愤怒，变成一个技术上可成立的新产品。
最关键的决策就是 Zig 和 JavaScriptCore。
第二阶段：品牌爆发期（2022.7-2023.9）
2022 年 7 月，Bun v0.1.0 发布后迅速出圈。早期社区买单的不是成熟度，而是三件事：
第一，统一叙事。 Node 时代的 JS 工具栈越来越像乐高------runtime 是 Node，包管理是 npm/yarn/pnpm，转译是 Babel/SWC/tsx，测试是 Jest/Vitest，打包是 webpack/esbuild/rollup/Vite。每多一层，就多一层配置、多一层 cache、多一层边界 bug。Bun 一上来就反着来：别拼了，我给你一个总工具。
第二，速度叙事足够强。 无论是早期官网还是后来的首页，Bun 一直把"快"放在最前面。启动快、HTTP 快、WebSocket 快、bun install 快、bun test 快。
第三，兼容策略更现实。 Deno 早期更像"重写现代 JS 运行环境"的宣言，理念漂亮但迁移成本高。Bun 从一开始就瞄准"Node 的替代者"，不是"Node 的批评者"。它不是要教育开发者换脑子，而是想让开发者带着旧项目直接试。
这件事非常重要。因为在运行时竞争里，迁移成本比理论优雅更接近真实决策。
第三阶段：平台化与兼容攻坚期（2023.9-2025.10）
Bun 1.0（2023.9.8）：第一次完成产品定义
Bun 1.0 不只是版本号从 0.x 跨到 1.0。真正重要的是，它第一次把产品定义讲完整了：明确列出想要替代 Node.js、npx、dotenv、nodemon、babel、ts-node、esbuild、webpack、npm、yarn、pnpm、Jest、Vitest。
它讲的不只是性能，而是一个完整的开发路径。
这背后是一种很强的产品哲学：不是让你装更多工具去修 JavaScript，而是让 runtime 本身长出更多"开发者真正高频会用"的器官。
Bun 1.1（2024.4.1）：补上 Windows，从明星项目走向平台项目
Windows 支持看起来不性感，但它决定你到底能不能被更大盘子的开发者采用。Bun 1.1 发布文里说，Bun on Windows 已经可以通过 Bun 在 macOS 和 Linux 上自用测试套件的 98%。
这一步的意义在于：你不再只是给愿意折腾的新技术爱好者服务，你开始对更多普通开发者负责。对基础设施产品来说，这是从"项目"走向"平台"的必要一步。
Bun 1.2（2025.1.22）：方法论升级
很多人看 Bun 1.2，会先看到新增能力：Bun.s3、Bun.sql、bun.lock 文本锁文件。
但我觉得真正的分水岭在于它对 Node.js 兼容性的方法论升级 。过去 Bun 修 Node 兼容，更多是哪个 npm 包炸了就去补哪个坑------像打地鼠。Bun 1.2 开始系统性地跑 Node.js 官方测试套件。
这意味着 Bun 承认了一件事：如果你真想吃掉 Node 的运行时地位，最重要的战场不是宣传页，而是兼容性回归测试。
这是 Bun 从"产品想象力很强"走向"工程纪律正在成形"的关键一步。
Bun 1.3（2025.10.10）：从 runtime 推向 full-stack substrate
官方原话：Bun 1.3 turns Bun into a batteries-included full-stack JavaScript runtime.
新增了内建前端 dev server、内建热重载、可以直接跑 HTML、更强的 Bun.serve() 路由、MySQL 和 Redis 也进来了。
到 1.3 为止，Bun 已经不再只想做"更快的 Node 替代品"。它想做的是：你用一门语言，一套命令，一个二进制，直接把前端开发、后端服务、测试、打包、依赖管理、甚至一部分数据库接入都串起来。
第四阶段：AI 基础设施绑定期（2025.12 至今）
被 Anthropic 收购
2025 年 12 月 2 日，Bun 宣布加入 Anthropic。Jarred 在公告里说得很坦白：截至公告发布时，Bun 收入是 0。
这很真实。Bun 过去默认的商业化设想大概是做某种云托管产品，但 AI coding tools 在 2024 年后突然变成更大的浪潮。Bun 团队判断，把自己放到 Anthropic 体系里，成为 Claude Code、Claude Agent SDK 和未来 AI coding 产品的基础设施层，比继续摸索独立 startup 如何变现更有意思。
这里有一个非常值得注意的转向：Bun 最早是因为前端热重载慢而生，最初服务的是"人类开发者更快写代码"。到了 2025 年底，新叙事变成：AI agents 正在写、测、跑更多代码，所以 runtime 和工具链层的重要性反而更高。
这不是换包装，是战略重心真的变了。
2026 年：继续打磨底层
截至 2026 年 5 月 6 日，我查到的 Bun 最新稳定版是 v1.3.13。这些 1.3.x 小版本说明 Bun 已经进入更像基础设施产品的第二阶段：围绕真实工作负载，打磨测试、安装、内存、兼容这些又难讲故事、又极其影响体感的底层路径。
比如 1.3.13 里：bun test --parallel、--isolate、--shard、--changed；bun install 流式解压 tarball，官方称在大仓库里把内存压到之前的 1/17；source map 内存占用最多下降 8 倍；runtime 基线内存再降约 5%。
竞争格局：Bun vs Node vs Deno
Bun 的竞品不是一个，至少有三类对手：Node.js（默认标准）、Deno（方法论型对手）、传统 Node 工具链组合（最真实的日常对手）。
Bun vs Node.js
Node 的价值不是"每一项都最好"，而是"它在无数真实生产环境里被证明足够稳，而且生态默认围着它转"。Node 自己不试图把整个工具链都吃下来，它把 runtime 做成公共地基，然后允许上层生态自由长。
Bun 则更激进。它不满足于做 runtime，它想把"你平时围绕 runtime 装的一整套常用工具"一起卷进来。
Bun 赢在：集成度极高、启动快反馈快（对 CLI 和 AI agent 特别友好）、产品表达更现代。
Bun 输在：稳定性和边缘兼容还没到 Node 那个量级、维护面过宽、生产可预期性仍然弱于 Node。
用户的真实选择逻辑通常是：
- 选 Bun：新项目、内部工具、CLI、AI agent，迁移包袱小，想少装几层工具
- 选 Node：老项目依赖深，团队更看重稳定性，生产事故成本远大于日常快一点的收益
Bun vs Deno
两者经常被放在一起，但方法论差很大。
Deno 的路线 ：先把原则立住，再向现实靠近。secure by default，Web 标准优先，TypeScript 零配置。Deno 2 的现实转向很明显：官方发布文明确提到支持 package.json、node_modules、npm 和更强的 Node 兼容。
Bun 的路线：先吃现实，再慢慢补原则。从第一天就强调"drop-in replacement for Node.js"，优先考虑的不是权限模型的美感，而是"老项目能不能尽快跑"。
三条路径，三种气质：
- Node 是默认公路
- Deno 是重新规划过交通规则的新城
- Bun 是一条想直接把老城最堵那几段全改成高速路的工程
Bun vs 传统工具链
这才是最真实的竞争。很多团队不会问"要不要从 Node 换到 Bun"，而是问：现有这套 Node + pnpm + Vite + Vitest 的组合，有没有必要整体迁到 Bun？
传统组合的优点是每一层都相对成熟，并且可以替换。缺点是你得自己承担拼装成本------不同工具会反复解析源码、反复做模块图、反复维护 cache。
Bun 赢在减少重复工作、配置面收缩、局部采用路径很丝滑（你可以先只用 bun install）。
Bun 输在传统组合的每个局部都更成熟，专业化工具在极端场景下仍然更强，而且很多成熟团队不喜欢"一个核心工具管太多事"。
Bun 的优势和劣势，都来自同一个源头
Bun 最让人着迷的地方，和最让人不放心的地方，其实是一回事。
它的核心优势来自一个很稳定的价值排序：凡是会拖慢开发者反馈回路的环节，都值得被系统性重做。 安装更快、启动更快、TypeScript/JSX 不用额外转、测试和打包都不绕远路、CLI 分发成本更低。
但正因为不是只做 runtime，而是一路把更多高频能力往 core 里收------包管理器、测试运行器、Bundler、dev server、数据库客户端、对象存储客户端------维护半径不断扩大。任何一个面出问题，都会牵连整个品牌。
GitHub 上能看到非常具体的担忧。有用户在用 Elysia.js + Prisma 的 API 服务里观察到 CPU 持续上升；也有用户把同一套服务从 Node 切到 Bun 后，在 GKE 上内存从 500MB 很快打到 1.2GB 容器上限。这些都是单个 issue 案例，不等于 Bun 在所有生产场景都有同样问题，但它们确实说明：社区对稳定性和边缘兼容的担心并不是凭空来的。
这些声音代表了 Bun 当前最真实的舆论断层：在开发体验层，很多人已经觉得它很香；在关键生产基础设施层，很多人还没有放心。
未来会怎样？
我觉得有三种剧本。
最可能：外围切入，向中心渗透
Bun 会继续成为 AI-native JavaScript 工具链和 CLI 分发的重要基础设施。很多团队会先用 bun install、bun test、可执行程序编译、内部脚本，再慢慢决定要不要让核心服务也切到 Bun。
最危险：功能扩张但质量跟不上
功能继续高速扩张，但质量治理跟不上，导致 Bun 在生产后端场景里长期背着"不够稳"的标签。最后更多停留在"很好用的开发工具/CLI 基座"，而不是全面替代 Node 的基础设施。
最乐观：AI 时代的默认 JS 执行层
Anthropic 的资源、AI coding tool 的真实需求、Bun 团队对性能和 DX 的持续偏执，最终叠加成一个结果：Bun 在 2 到 3 年里把 Node 兼容和稳定性再往前推一个台阶，成为 AI 时代默认的 JavaScript 执行与分发层。
写在最后
回头看看 Bun 的发展历程，有一个感受很深。
Node 代表的是"runtime 做小，生态做大"。Deno 代表的是"先把原则立住，再兼容现实"。Bun 代表的是"把最影响效率的几层工具重新焊成一个整体，并且优先服务真实迁移路径和更短的反馈回路"。
所以 Bun 最核心的竞争力，从来不只是快。而是它在试图把"现代 JavaScript 工程到底应该由几层工具组成"这个问题，重新回答一遍。
这就是它值得被认真研究的地方。也是它注定会继续伴随争议的原因。
对于普通开发者，我的建议是：
如果你在做新项目、CLI 工具、内部工具、AI agent 相关的东西，Bun 值得认真试试。你可以先只用 bun install 或 bun test，先吃到局部收益，不需要一步到位。
如果你在维护大型生产系统，继续用 Node 是更安全的选择。Bun 还没到可以放心把核心服务压上去的阶段。
但不管你用不用 Bun，它正在改变 JavaScript 工具链的游戏规则。这件事本身就很值得关注。