作为一个 Rust 热爱者，我为什么越来越喜欢 Bun？

前两天，我做了一件很“冲动”的事：把机器上的 pnpm、yarn 一类工具都删了，只留下了 bun。

这不是情绪化决定，而是过去一段时间真实使用之后的结果。

但先把立场说清楚：我依然是个 Rust 热爱者。

我喜欢 Rust，不只是因为它快，而是因为它在工程上给人一种很强的信心：

边界清楚、抽象克制、类型系统有力量、性能和可维护性往往能一起成立。

也正因为我很喜欢 Rust，所以我最开始看 Bun 和 Zig，其实是带着一点挑剔甚至怀疑的。

结果越用 Bun，越觉得它值得认真写一篇。因为它让我产生的不是“换了个包管理器”的新鲜感，而是另一种熟悉的敬意：

一个工程团队，真的在试图从底层重新整理整个工具链。

最近随着 Claude Code 的 source map 暴露事件，很多人也注意到它的工程里大量使用了 Bun。对我来说，这件事最有启发的地方，不是“某个明星项目也在用 Bun”，而是另一个问题：

为什么越来越多对启动速度、交互体验、工程统一性极度敏感的项目，会认真选择 Bun？

这篇文章，我想聊三件事：

1. Bun 到底是什么，为什么它会让人用了就回不去
2. 从 Bun 身上，我们能学到哪些工程思维
3. 如果你被 Bun 背后的 Zig 吸引了，应该怎么快速入门

---

Bun 到底不是“更快的 Node”，而是“重新做了一遍 JavaScript 工具链”

很多人第一次听说 Bun，会把它理解成：

一个更快的 Node.js 替代品。

这个理解不能说错，但不够准确。

Bun 真正厉害的地方在于，它不是只想替代 Node，而是想把过去前端和 Node 生态里四分五裂的工具链，重新收拢起来。

在传统 JavaScript / TypeScript 开发里，我们经常会这样组合：

• 运行时：Node.js
• 包管理：npm / pnpm / yarn
• 测试：Jest / Vitest
• 打包：Vite / esbuild / Rollup / Webpack
• 脚本执行：各种 shell + cross-env + tsx + nodemon

而 Bun 的思路是：

这些能力，为什么不能尽量在一个统一的二进制和一套统一语义里完成？

于是你就得到了一个非常激进、但也非常有吸引力的东西：

• bun install
• bun run
• bun test
• bun build
• bunx

看起来只是少记几个命令，但本质上发生的是：

原来散落在多个工具、多个作者、多个配置系统中的能力，被收编到了同一个 runtime 的世界观里。

这就是 Bun 最迷人的地方。它不是“一个快一点的工具”，而是“一个更统一的工程入口”。

---

为什么我用了 Bun 之后，开始嫌弃 pnpm / yarn / 一堆辅助工具

先说结论：

Bun 给人的最强体验，不是 benchmark 数字，而是“摩擦感显著下降”。

很多工程工具并不是不能用，而是用起来总有很多小摩擦：

• 安装依赖慢一点
• 冷启动慢一点
• 测试跑起来再等一下
• 多一个配置文件
• 多一个适配层
• 多一个脚本 hack

这些问题单独看都不致命，但叠加起来就会非常烦。

Bun 的价值就在于：它把这些小摩擦一口气砍掉了一大批。

1. 安装依赖更直接

以前一个项目装依赖，脑子里先想的是：

• 用 npm？
• 用 pnpm？
• 用 yarn？
• monorepo 怎么配？
• lockfile 怎么迁？

现在很多项目里，我直接就是：

bun install

没有那种“工具选择焦虑”，也没有那么多“先决定生态阵营，再开始干活”的心理负担。

2. 运行 TypeScript / JSX 的路径更短

很多过去需要 ts-node、tsx、nodemon、babel 参与的场景，在 Bun 里都被直接吸收进 runtime 了。

这件事的意义不是“少装几个包”，而是：

你会开始重新审视，哪些工具原本就是历史补丁。

3. 测试、构建、脚本不再像是不同世界

Node 生态里最让人疲惫的地方之一，就是：

• 运行环境一套语义
• 测试环境一套语义
• 打包环境一套语义
• dev server 又是一套语义

每个工具都能跑，但边界一多，心智负担就上来了。

而 Bun 在很大程度上是想把这些场景重新统一起来。

这就是为什么很多人从“试试看”开始，最后变成“怎么现在越来越多项目都想先用 Bun 起步”。

---

最近 Claude Code 事件，为什么会让更多人重新关注 Bun？

最近不少开发者在讨论 Claude Code 的源码暴露事件。公开流传出来的内容显示，Claude Code 的工程中大量使用了 Bun。

这件事本身当然有很强的话题性，但我更关注它背后释放出来的信号：

当一个对 CLI 体验、冷启动速度、工程集成度极其敏感的 AI 编码工具选择 Bun，这本身就是一种很强的技术背书。

为什么？

因为 Claude Code 这类产品对下面这些指标都非常敏感：

• 启动够不够快
• CLI 交互是否丝滑
• 子命令、脚本和构建链是否统一
• 跨平台行为是否稳定
• 单文件发布和升级是否方便

这些需求，恰好就是 Bun 擅长的地方。

所以从这个角度看，Claude Code 使用 Bun 不是“偶然”，而是“产品形态和工程约束自然收敛后的结果”。

当然，这里也要保持一个理性态度：

一个知名项目使用某个技术，并不等于那个技术适合所有团队。

但它至少说明了一件事：

Bun 已经不是一个只能拿来玩 demo 的新玩具，而是在真正进入高要求工具链和产品工程的主战场。

---

Bun 最值得我们学习的，不只是“快”，而是三种工程思维

很多人聊 Bun，最爱聊 benchmark。

我反而觉得，Bun 真正值得学的，不只是性能，而是它背后的工程方法论。

1. 一体化思维：把高频场景收回核心系统

过去很多生态都有一个惯性：

先把核心做小，剩下的都交给插件、三方库和社区。

这条路线当然有它的价值，但也很容易走向另一个极端：

核心越来越薄，项目越来越依赖外部拼装。

Bun 反其道而行之。

它做的不是“更小的 runtime”，而是“更强的默认能力集合”。

从 Bun 身上最值得学的一点就是：

对于高频、稳定、强共性的场景，不一定非要永远外包给三方生态。

当某件事已经成为 80% 用户的日常刚需时，把它做回系统内建能力，往往能带来更低的复杂度和更好的体验。

这个思路对我们做后端框架、基础设施平台、甚至内部开发工具都很有启发。

2. 少一层，就是生产力

Bun 的很多优势，说到底都来自一句话：少一层。

• 少一层 CLI 包装
• 少一层 JS 胶水
• 少一层进程跳转
• 少一层配置转换
• 少一层构建补丁

工程里很多复杂度，并不是算法本身复杂，而是系统层数太多。

所以从 Bun 身上能学到的第二点是：

优化系统，不一定要从最难的算法下手；很多时候，先把中间层砍掉，收益就已经很大。

3. 性能不是一个点，而是一整套设计纪律

为什么 Bun 快？

不是因为某个模块“神优化”，而是因为它从架构一开始就考虑了：

• 启动成本
• 内存分配
• 构建系统
• 语言边界
• 运行时能力
• 工具链统一

这其实是一种非常值得学习的工程纪律：

性能不是后期打磨出来的，而是前期设计决定的。

很多团队一开始只关注“功能先做出来”，等到后面再想补性能，往往很痛苦。

Bun 给人的启发是：

真正优秀的工程，不是某个 benchmark 冲到第一，而是从第一天开始就在避免未来的性能债和复杂度债。

---

作为 Rust 热爱者，我怎么看 Bun 选择 Zig 这件事？

聊到这里，就绕不开 Zig 了。

Bun 的核心 runtime 主要是用 Zig 编写的，底层则基于 JavaScriptCore。对很多人来说，Bun 其实也是第一次让 Zig 真正进入自己的视野。

那么问题来了：

为什么 Bun 选 Zig，而不是 Rust / C++ / Go？

先说我的态度：这并不构成对 Rust 的否定。

如果今天让我做很多基础设施项目、后端服务、区块链组件、数据库中间层，Rust 依然大概率是我的第一选择。Rust 在内存安全、并发安全、抽象表达力和长期可维护性上，仍然有非常强的吸引力。

但 Bun 不是一个普通后端项目。它是一个：

• runtime
• bundler
• package manager
• test runner
• dev server

揉在一起的系统软件项目，而且它还要深度贴着 JavaScriptCore、C/C++ ABI、Node 兼容层这些边界去生长。

在这种约束下，Zig 的优势就会变得非常具体：

• 足够接近 C，和底层 ABI 打交道很直接
• 没有额外 runtime 和 GC 世界观
• 内存分配策略可以完全自己设计
• 语言复杂度明显低于 C++
• 在“我知道自己在做什么”的前提下，改动路径很短

而这几件事，恰好都很适合 Bun 这种项目。

作为 Rust 用户，我觉得这件事最值得尊重的地方不是“Zig 比 Rust 更强”，而是：

Bun 团队非常清楚自己在优化什么，也非常清楚自己愿意承担什么代价。

Rust 的强项是：尽量在编译期替你兜住很多错误。 Zig 的强项则更像是：我不给你太多魔法，但把控制权尽量完整地交给你。

所以如果用一句更公平的话来总结：

• Rust 更像一门高保障的系统语言
• Zig 更像一门高控制感的系统语言

Bun 之所以选 Zig，不是因为 Rust 不够优秀，而是因为 Zig 更贴合它当下的工程取舍。

这也是我写这篇文章时特别想强调的一点：

喜欢 Bun，不等于要背叛 Rust。

相反，正因为我喜欢 Rust，我才更能看懂 Bun 的价值：

一个真正优秀的系统项目，最重要的不是选了哪门“神语言”，而是有没有围绕自己的约束做出一致、诚实、长期主义的工程决策。

从 Bun 学 Zig：不要一上来就学语法，先学它的世界观

很多人一听说 Zig，第一反应是：

要不要找一本 Zig 教程，从语法开始学？

当然可以，但我更建议另一条路线：

先从 Bun 这类真实项目反向理解 Zig 的价值，再回去学语言本身。

为什么？

因为 Zig 不是那种“语法很炫”的语言。它真正吸引人的地方，是系统编程里的几种思维方式：

• 明确的内存所有权和生命周期
• 少魔法、少隐藏控制流
• 把分配器当成显式设计对象
• 贴着平台边界写代码
• 在性能和可维护性之间做直接权衡

如果你先理解了 Bun 为什么需要这些东西，再学 Zig，就会非常顺。

---

如何快速入门 Zig：一条最短路径

这里我给一个我认为更适合工程师的 Zig 入门路线。

不是“系统学完语法再写项目”，而是边用边学。

第一步：先建立正确认知

你需要先接受一个事实：

Zig 不是一门“帮你自动做很多事”的语言。

它更像是在不断提醒你：

• 这块内存是谁分配的？
• 谁来释放？
• 生命周期多久？
• 这里是不是在隐式拷贝？
• 这个错误要怎么显式传播？

如果你以前主要写 Java / Go / TypeScript，这会有一点不适应。

但这恰恰是 Zig 最有价值的地方。

第二步：只学最关键的 20%

刚开始不用追求全面掌握，先抓住最重要的内容：

1. 基本语法：变量、函数、struct、enum、switch、error union
2. 指针与 slice
3. allocator 的基本使用
4. defer / errdefer
5. 错误处理模型
6. 与 C 互操作的基本方式
7. build.zig 的基本概念

你会发现，学完这些，已经足够读很多 Zig 项目的核心代码了。

第三步：写三个极小练习

不要一上来写大项目，先写三个小东西：

练习 1：实现一个简单的字符串处理 CLI

目标：

• 读命令行参数
• 处理字符串
• 输出结果

作用：熟悉语法、标准库、基本 I/O。

练习 2：手写一个简单的文件扫描工具

目标：

• 遍历目录
• 读取文件
• 统计行数 / 单词数 / 后缀名

作用：熟悉文件系统接口和错误处理。

练习 3：写一个带 allocator 的小型 parser

目标：

• 解析一小段 DSL / 配置文本
• 自己分配和释放对象

作用：开始真正理解 Zig 为什么强调显式内存管理。

第四步：开始读 Bun 这种大项目的局部代码

这个阶段不要试图一口气看懂整个 Bun。

你只需要挑几块最有代表性的：

• build.zig：看 Zig 怎么做构建系统
• src/bundler/：看 Zig 怎么做高性能内存管理
• src/install/：看 Zig 怎么组织复杂状态机

哪怕你一开始只能看懂 30%，也会比单纯刷语法题进步更快。

第五步：做一个你自己用得上的工具

学习系统语言最好的方式，不是做 LeetCode，而是做一个你每天真会用的小工具。

比如：

• 一个日志清洗工具
• 一个批量重命名工具
• 一个本地代码扫描器
• 一个小型代理/转发器
• 一个简单的代码生成器

只要你真的会每天运行它，你对 Zig 的理解就会快速加深。

---

如果你本来就喜欢 Rust，该怎么判断自己要不要学 Bun 和 Zig？

我的建议很简单。

Bun 值得学，如果你：

• 经常写 Node / TypeScript 工具
• 讨厌繁琐的脚本和配置
• 很在意开发反馈速度
• 对更统一的工程体验有要求
• 做 CLI、构建工具、AI coding 周边工具比较多

哪怕你最终还是继续用 Rust 做主力后端，Bun 也依然值得你认真用一段时间。 因为它会让你重新思考：

• 什么能力应该内建进 runtime
• 什么能力只是历史补丁
• 什么复杂度其实可以被整体收编

Zig 值得学，如果你：

• 想往底层和系统方向再走一步
• 想真正理解内存、分配器、运行时和构建系统
• 对高性能工具链实现感兴趣
• 想提升自己的工程“底层视角”

但如果你已经是 Rust 用户，我的建议不是“立刻转向 Zig”，而是：

把 Zig 当成一个帮助你扩展系统视角的补充语言。

Rust 会继续给你：

• 强类型约束
• 内存与并发安全
• 更稳健的大型工程体验

而 Zig 会提醒你另一套东西：

• 更直接的 ABI 思维
• 更显式的分配器意识
• 更少语言魔法时，系统代码会长什么样

这两者不是非此即彼，反而非常适合互相参照。

对我来说，最舒服的姿势其实是：

• 继续热爱 Rust
• 认真使用 Bun
• 把 Zig 当成理解现代工具链实现的一把钥匙

Bun 给我的最大启发，不是换了一个包管理器

表面上看，我做的只是删掉了 pnpm、yarn，换成了 bun。

但更深层的变化其实是：

Bun 让我重新意识到，很多我们习以为常的工具链复杂度，并不是天经地义。

我们过去在 JavaScript 生态里接受了太多“理所当然”的东西：

• 多个包管理器并存
• 多套测试体系并存
• 多种构建工具叠加
• 大量脚本胶水
• 一层又一层历史兼容补丁

而 Bun 做的一件很有野心、也很有价值的事，就是试图把这些碎片重新收拢起来。

它不一定已经在所有场景里都完美，但它至少证明了一件事：

更统一、更少层次、更强调默认体验的工具链，是完全有机会赢得开发者的。

而 Zig 则是这个故事背后更深的一层：

它提醒我们，优秀的工程工具，不只是 API 设计得好看，更重要的是底层实现足够克制、足够直接、足够尊重系统本身。

如果说 Bun 是“让我重新对 JavaScript 工具链产生信心”的项目， 那么 Zig 更像是“让我用另一种角度重新审视系统编程”的入口。

而 Rust，依然是那个让我在真正落地复杂工程时，最有安全感的老朋友。

对我来说，这可能才是 Bun 最值钱的地方。

---

结尾

作为一个 Rust 热爱者，我并不觉得 Bun 和 Zig 的出现是在取代 Rust。

真正让我兴奋的，是另一件事：

优秀的工程项目，总会逼着我们跳出语言阵营，重新思考系统该如何被构建。

Bun 让人看到，一体化、少层次、强默认能力的工具链依然有巨大生命力。 Zig 让人看到，很多性能与控制力，来自对底层边界的诚实面对。 而 Rust 则继续提醒我们，复杂系统的长期演化，同样需要强约束带来的安全感。

所以对我来说，这不是一个“站队哪门语言”的故事。

这是一个关于工程判断的故事：

• 什么场景该追求更强的控制感
• 什么场景该追求更高的安全性
• 什么场景该把复杂度收回系统内部
• 什么场景该用更少的层换来更高的效率

很多时候，真正改变我们的，不是某个工具赢了。

而是我们终于开始用更成熟的方式理解工具背后的取舍。