背景、演进与学习路线

到这一章，运行时、打包器、测试、包管理、Web 框架、部署与性能都走完了。最后一章不讲具体 API，把镜头拉远看三件事：Bun 从哪里来、现在往哪里去、你接下来怎么走。

了解背景不是「看故事」。它能帮你分清哪些是稳定承诺、哪些只是方向性预告，从而不被社区流言和镜像站水文带偏。

34.1 Bun 是怎么来的

起点：一次 45 秒的等待

创始人 Jarred Sumner 讲过一个很朴素的起点。2021 年他在浏览器里做一个类似 Minecraft 的体素（voxel）游戏，代码库越写越大，每改一次都要等 Next.js 开发服务器热重载，一轮迭代要花 45 秒。

时间全耗在等待上，他实在受不了，于是「分心」去解决这个问题。

第一个动作是把 esbuild 的 JSX 与 TypeScript 转译器从 Go 移植到 Zig。三周后，一个能用的转译器出来了。

为了让 Next.js 的服务端渲染跑起来，他还需要一个 JavaScript 运行时。于是去啃 WebKit 源码，研究怎么像 Safari 那样内嵌 JavaScriptCore，做出了 Bun 运行时最早的雏形。

这里有个关键选择：Bun 用的是 JavaScriptCore（Safari 引擎），而不是 V8（Chrome/Node 引擎）。原因之一是 JSC 启动明显更快——这正对着「让开发者更快」这个目标。

版本演进脉络

沿着这条线，Bun 的版本演进大致如下：

• Bun v0.1.0（2022 年 7 月）：首次公开发布。它把打包器、转译器、运行时（定位为 Node.js 的 drop-in 替代品）、测试运行器、包管理器「五合一」打包在一起。发布第一周就拿到 2 万 GitHub stars。
• Bun v1.0.0（2023 年 9 月）：稳定性显著提升，生产使用开始增长，团队扩张到约 14 人。
• Bun v1.1：补上了呼声最高的短板——Windows 支持（早期还很粗糙，后续持续改进）。
• Bun v1.2：大幅改进 Node.js 兼容性，新增内置 PostgreSQL 客户端与 S3 客户端，X、Midjourney 等公司开始在生产中使用。
• Bun v1.3：新增内置前端开发服务器、Redis 客户端、MySQL 客户端，并持续改进 bun install 与 Node.js 兼容性。

34.2 加入 Anthropic：变与不变

2025 年 12 月，Bun 官方博客宣布 Bun 加入 Anthropic，Anthropic 同日发布了对应公告。对普通用户来说，最该抓住的是「什么变了、什么没变」这一组对照。

没有改变的：

• Bun 仍然保持开源、MIT 许可证不变。
• Bun 仍然由同一支团队全职维护，并且继续在 GitHub 上公开构建（built in public）。
• Bun 的路线图核心不变：继续聚焦高性能 JavaScript 工具链、Node.js 兼容性，以及「成为服务端 JavaScript 默认运行时、替代 Node.js」这一目标。
• 对现有用户的核心承诺不变：依然是那个让你更快安装、构建、运行、测试 JavaScript 与 TypeScript 的工具。

发生变化的：

• Bun 团队会与 Claude Code 团队更紧密协作，优先让 Claude Code、Claude Agent SDK 等 AI 编程产品更快、更小。
• Bun 能更早地看到 AI 编程工具的演进方向，并据此调整自身。
• 发布节奏会更快。

还有个常见误解：加入 Anthropic 后，Bun 会不会变成「闭源、只服务 Anthropic 自家产品」的工具？

答案是否定的。MIT 许可证、公开仓库、同一团队、开放路线图这四点，官方公告里逐条确认过。换个角度看，Bun 从「零营收的 VC 支持创业公司」变成了「顶级 AI 实验室的基础设施部门」——它跳过了「被迫思考怎么赚钱」这一章。

34.3 Zig→Rust 重写：背景与边界（方向性）

这是本章最容易读歪的部分，请务必结合红线理解。

事实边界

Bun v1.3.14 是最后一个用 Zig 写成的版本。 2026 年 7 月 8 日，官方博客《Rewriting Bun in Rust》宣布整个代码库已从 Zig 重写到 Rust。

但这不是一个已经交付给稳定版用户的新特性，而是进行中的、方向性的工程演进。截至本教程基线 v1.3.14，你手里跑的仍然是 Zig 实现；Rust 写成的 Bun 属于下一个大版本 v1.4.0，目前只在 canary（预览）通道提供。

为什么要换语言

核心动机是稳定性，不是性能。

Bun 公开的 bug 清单里，大量是 use-after-free、double-free、错误路径「忘记释放」这类内存安全问题。它们大多来自同一个源头：GC 管理的 JavaScript 值，和手动管理内存的底层值，两者生命周期交织在一起。

Zig 靠显式 defer 清理资源，要求开发者在每个调用点都小心翼翼；Rust 的借用检查器与 Drop 则能在编译期就把这类问题拦下来。官方的原话是：编译器报错，比一份代码规范更适合当反馈机制。

重写过程本身

这次重写是个相当惊人的工程案例。据官方博客披露，主要由一名工程师借助 Claude Code 的动态工作流完成，耗时 11 天，峰值同时跑约 64 个 Claude 实例，产生 6,502 次非合并提交（连合并提交算约 6,778 次）。

跨平台的既有测试套件全部通过、零跳过。能这么干有个重要前提：Bun 的测试套件是用 TypeScript 写的，不依赖底层实现语言——这让「换语言重写但行为不变」有了客观验收标准。

从已公开的对比数据看，Rust 版（v1.4.0 canary）相对 v1.3.14 带来了：

• 修复 128 个在 v1.3.14 中可复现的 bug，从内存泄漏、崩溃到帮助文本配色错误都有。
• 更省内存：同一项目在单进程里反复打包 2000 次，v1.3.14 内存一路涨到约 6.7 GB，v1.4.0 稳定在约 609 MB。
• 更小的二进制：Linux/Windows 体积缩小约 20%（Linux 从约 88 MB 降到约 70 MB）。
• 快一点点：HTTP 吞吐与常见构建任务普遍有 2%–5% 的提升。

如果你确实想提前体验 Rust 版，可以通过 canary 通道安装：

bun upgrade --canary

但再次提醒：canary 是预览性质，可能包含尚未稳定的行为，不要用在生产上。

34.4 版本节奏与路线图

理解发布节奏，才好判断「什么时候该升级、什么时候该等」。

Bun 用语义化的 主版本.次版本.修订号。v1.3.x 是一条很长的稳定线，从 v1.3.0 一路走到 v1.3.14，每个修订号都在补 Node.js 兼容性、修 bug，同时塞进增量能力。

这条线上比较有代表性的能力包括：bun test 的 --isolate / --parallel / --shard、内置 Bun.WebView、Bun.cron()、直接在终端渲染 Markdown。发布频率相当高，几乎每隔几周就有新修订号，是典型的「小而快」节奏。

从路线图角度，可以概括为三句话：

1. 短期（已发生）：v1.3.x 系列把运行时、打包器、测试、包管理器打磨到生产可用，并补齐 Windows、原生客户端、前端开发服务器等能力。
2. 中期（进行中）：v1.4.0 把实现语言从 Zig 迁移到 Rust，目标是系统性提升稳定性、降低内存与体积。这是一次「内部实现」的换代，对外的 API 与行为尽量保持不变。
3. 长期（方向）：继续聚焦「更快的 JavaScript 工具链 + 更强的 Node.js 兼容 + 成为 AI 编程时代的基础设施」。加入 Anthropic 后，Bun 会更多地面向 Claude Code 等 AI 编程产品的真实需求做优化，但这与「做一个好用的通用 JavaScript 运行时」并不冲突。

34.5 全教程能力地图：你学到了什么

回顾这 34 章，Bun 的本质一句话就能概括：把运行时、打包器、测试运行器、包管理器这四件原本独立的工具，收进同一个二进制、同一个引擎（JavaScriptCore）里重新设计一遍。

下面这张地图帮你把前面零散的知识点串起来：

• 运行时（Runtime）：用 bun run 直接跑 TS/JSX/JSON 等，无需预编译；Bun.serve 内置 HTTP 与 WebSocket 服务器；Bun.* 家族提供文件、哈希、SQL、WebSocket、cron、shell 等原生 API。
• 打包器（Bundler）：bun build 把 TS/JSX/CSS 打包成单文件或独立可执行文件（--compile），支持插件、代码分割、sourcemap、压缩等。
• 测试（Test）：bun test 提供 Jest 风格的断言、匹配器、mock/spy、快照、覆盖率与生命周期钩子，且与运行时共享同一套转译能力。
• 包管理（Package Manager）：bun install 官方给出的数据是最多比 npm 快 30 倍，兼容 package.json 与 node_modules，支持工作区、文本锁文件 bun.lock、镜像源与离线安装。
• 生态与部署：Elysia、Hono 等原生框架建立在 Bun.serve 之上；Docker、Vercel、Railway、Render、云函数等都有成熟的部署路径。
• 性能与背景：JavaScriptCore + uWebSockets + mimalloc + SIMD + 一体化工具链，是 Bun「快」的底层原因；而 Zig→Rust 重写则是它面向下一个十年的稳定性投资。

如果你能对着这张地图，把每一条背后的核心命令与典型片段复述出来，这套教程的目标就达成了：不再把 Bun 当成「另一个 Node」，而是理解它作为一体化 JavaScript 工具链的设计取舍。

34.6 下一步学习路线

教程有终点，但 Bun 的学习没有。下面几条路线按「由近及远」排列，你可以根据自己的目标选择：

1. 把教程里的片段变成小项目。学完不等于会用。挑一个你熟悉的场景（比如一个带数据库的 CRUD API、一个 CLI 工具、一个用 --compile 打包的单文件程序），用 Bun 从零做一遍，遇到报错就回到对应章节查。
2. 深入一个原生框架。第 31 章只讲了路由、生命周期、校验、插件四个概念。真正上手建议选 Elysia 或 Hono 之一，读完它的官方文档，做一个完整的小服务，体会生命周期钩子与 Schema 校验怎么组合起来。
3. 读官方文档与源码。Bun 的官方文档是「事实的唯一来源」。当社区教程与文档冲突时，永远信文档。awesome-bun 清单里汇集了大量生态项目，是找灵感的好地方。
4. 关注 v1.4 与 Rust 重写。当你读到这一章时，如果 v1.4 已经发布为稳定版，请重新以新版本基线核对行为差异（尤其是升级带来的语义变化，官方博客列举过若干「两种语言语法相同但语义不同」的回归案例）。
5. 参与社区与贡献。Bun 在 GitHub 公开构建，issue 与 PR 都公开。即便你不写底层 Zig/Rust，也可以通过提交复现最小用例、完善文档、在 Stack Overflow 或 Discord 回答问题来回馈生态。

走到这里，你已经具备了独立使用 Bun 完成真实任务的知识基础。Bun 仍在快速演进，保持对官方信息的关注、保持「用事实源而非水文」的判断力，比记住任何单条命令都更重要。祝你在更快的 JavaScript 工具链上，写出更顺手的项目。