为什么 Bun 这么快?深入解析 Zig + JavaScriptCore + Bundler 架构
By Leeting Yan
深入解析 Zig Runtime + JavaScriptCore + 全能 bundler 架构
Bun 的目标非常明确:做最快的 JavaScript Runtime 与“前端工具链的一体化替代品”。
Bun 之所以“快到不合理”,并不是某一个组件做得好,而是 整体架构选择 + 工程策略 + 极度工程化优化 的结果。
总结来说:
Bun 快,是因为它不是“做得比 Node 好一点”,而是整个运行时和工具链都重新设计过。
本文从架构视角解释 Bun 的核心性能来源。
1. Bun 的整体架构图(Birdor 风格)
┌──────────────────────────────────────────────┐
│ JavaScript (User Code) │
│ CJS / ESM / Bun.imports 统一支持 │
└──────────────────────────────────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ Bun Runtime API Surface │
│ fs / http / net / process / timers … │
└──────────────────────────────────────────────┘
│
▼
┌──────────────────────────────┬────────────────┐
│ JavaScriptCore (JSC) │ Zig Runtime │
│ JIT + GC + bytecode engine │ event loop, IO│
└──────────────────────────────┴────────────────┘
│
▼
┌──────────────────────────────────────────────┐
│ OS │
│ epoll / kqueue / IOCP │
└──────────────────────────────────────────────┘
Bun 并不是一个 JS 引擎,而是:
- 用 Zig 写的高性能运行时
- 使用 WebKit 的 JavaScriptCore (JSC) 作为 JS 引擎
- 内置 超高速 bundler、transpiler、测试框架、包管理器
- 自研事件循环和网络层
这种“从头设计一个更现代的 Node.js”的架构,是 Bun 速度的根本来源。
2. 性能来源之一:Zig 实现的 runtime(不是 C++)
Bun 的 runtime(事件循环、模块解析、文件系统调用、HTTP 层等)全部用 Zig 写。
Zig 的优势:
2.1 更可控的内存模型:无隐藏分配、无异常开销
C++ 的“隐式成本”包括:
- 隐式拷贝
- 隐式构造 / 析构
- 异常机制(zero-cost exception)
- 不可控分配行为(std::string / vector)
Zig 的设计完全相反:
- 不允许隐藏内存分配
- 不允许隐式错误传播
- 所有内存都必须在代码中显式体现
- 错误采用
error!T形式,成本可控且无异常机制
结果:
- 更低延迟
- 更紧凑的机器码
- 更符合 runtime 的需求
2.2 Zig 拥有极快的编译速度与可压缩的部署
Zig 生成的产物:
- 无 C++ 复杂 RTTI
- 无额外运行时依赖
- 工程结构更清晰
相比 NodeJS 的庞大 C++ glue 层,Zig runtime 更容易做到 “持续微优化”。
2.3 工程团队可以在 runtime 层面做激进优化
因为 Zig 的可控性,Bun 选择了:
- 更快的 UTF-8 解析器
- 基于 SIMD 的 HTTP 解析器
- 自研事件循环
- 零拷贝 Buffer
这清晰解释了:
Bun 并不是“优化 Node”,而是“重写 Node 的底层”。
3. 性能来源之二:JSC(JavaScriptCore)比 V8 更适合某些场景
Node.js 和 Deno 使用 V8,而 Bun 使用 JavaScriptCore (JSC)。
为什么这是优势?
3.1 JSC 的 baseline JIT 更轻量、启动更快
V8 的优化管线(Ignition → TurboFan)非常强大,但有较高的启动成本。
JSC 的 JIT 是:
- 更小
- 更快进入 steady-state
- 更适合“工具链”风格的短命进程
- 更快 eval 和 module load
这就是为什么:
bun run比node app.js启动快数十毫秒- Bun 的 CLI 工具几乎没有“冷启动”
在 dev server 场景中是巨大的优势。
3.2 JSC 的 GC 设计对典型工具链 workload 更友好
V8 更适合大型 Web App 的对象生命周期策略;
JSC 更适合:
- 小对象
- 短生命周期
- 密集解析和执行的工具链场景
Bun 恰好是“工具链一体化 Runtime”,因此这一点直接变成性能优势。
4. 性能来源之三:bundler、transpiler、resolver 全部内置(并用 Zig 写)
Bun 最大的黑科技之一,是它的 bundler:
- 比 esbuild 还快(后者是 Go 写的,已经非常快)
- 因为 Bun 直接基于 Zig + JSC 一体化处理整个 pipeline
Bun 的 bundling pipeline:
Parser (Zig)
↓
AST (密集优化)
↓
Transform (Zig)
↓
Codegen (Zig)
↓
Runtime Integration (JSC)
相比:
- Webpack → JS + Node API
- Rollup → JS 大量 AST 操作
- esbuild → Go(仍需要和 Node 交互)
Bun 做到了:
- 全流程一次性
- 单进程
- 零 context switch
- 无需序列化/反序列化
- 直接内存共享
这就是为什么:
bun build app.ts # 比 esbuild 更快
bun install # 比 npm 快十倍以上
bun test # 比 jest 快几十倍
5. 性能来源之四:自研网络层 + 零拷贝设计
Node.js 的网络层高度依赖 libuv,而 Bun 选择了更现代、更轻量的架构。
5.1 Bun 的 HTTP 服务器比 Node 快非常多的原因:
- SIMD 加速 HTTP 解析
- Zero-copy buffer
- 更轻量的事件循环
- 没有 legacy 行为兼容的负担
例如,Bun 的 HTTP parser:
- 用 Zig 写
- 用大量
@Vector(SIMD)操作优化 tokenization - 比 Node 的 parser 快 一个数量级
6. 性能来源之五:更现代的模块解析系统
Node 的模块解析逻辑(CJS + ESM + pkg.exports + fallback)非常复杂:
- 需要查找多层目录
- 多种文件扩展名
- 多种包入口策略
Bun 采用:
- 更少的 fallback
- 更少的猜测
- 更标准化的 ESM 解析
模块解析越少 → 冷启动越快。
7. 性能来源之六:集成式工具链减少跨进程开销
传统工具链:
tsc → node
babel → node
jest → node
webpack → node
每一步都可能:
- 启动 Node
- 加载大量 JS 文件
- 运行用户态 JS
Bun 的设计是:
Runtime, Bundler, Test Runner, Transpiler 全部在一个进程。
减少了:
- 进程启动成本
- 模块加载成本
- JS AST 反复解析成本
这使得 Bun 在工具链维度的表现几乎“碾压同类”。
8. 性能来源七:更少的历史包袱
Node.js 的性能上限受历史设计限制:
- CJS 必须支持
- Buffer API 不能破坏
- libuv 事件循环行为不能变
- 大量边缘行为必须兼容 Express / React 等框架的数十亿代码
而 Bun:
- 没有十多年前遗留的 API
- 没有必须兼容的 C++ addon 生态
- 没有必须保持一致的定时器行为
- 模块解析几乎完全自由设计
越少的历史包袱 → 架构越纯粹 → 优化空间越大。
9. 为什么 Bun 快得“不合理”?(总结)
Bun 快,是因为它同时具备:
✔ Zig → 明确可控、不隐式开销的系统语言
✔ JSC → 启动快、JIT 轻量、适合工具链
✔ 自研 runtime → 网络层、事件循环高度定制化
✔ 全流程一体化 → bundler / transpiler / test / npm client 全部内置
✔ SIMD 优化 → parse JSON、解析 HTTP、基础库
✔ 零拷贝设计 → buffer 和 IO path 极短
✔ 没有历史包袱 → 不需要兼容 Node 过去 10 年的行为
一句话总结:
Bun = 现代化工程能力 + 极限优化策略 + 从底层重写 Node 的勇气。
它不是“稍微比 Node 快”,而是配置了完全不同的底层能力。
10. Bun 是否会取代 Node.js?
短期:不会。
长期:Bun 会成为本地开发工具链的主流候选。
定位更像:
- Bun → 快速构建、测试、开发(工具链革命)
- Node → 稳定的生产 runtime
- Deno → Web 标准化 + 更安全的 runtime
未来可能是“三分天下”,不是一方取代另一方。
结语
Bun 并不是一个“更快的 Node.js”,而是一个重新设计过的现代 JavaScript Runtime:
- 更快
- 更轻
- 更一致
- 更工程化
Zig + JSC + 自研工具链,使得 Bun 在架构上具备天然的速度优势。