Bun 深度实战：Zig + JavaScriptCore 如何把 Node 的「慢启动 + 碎片工具链」旧账一次性清掉——从 bun install 提速 30 倍到 Bun.serve 生产级服务全链路拆解

一个资深的 Node 工程师，每天要跟多少工具打交道？npm/pnpm 装依赖，esbuild/webpack/rollup 打包，tsc/babel 转译，jest/vitest 跑测试，nodemon 热重载，prettier 格式化……光是把这份工具清单维护到不互相打架，就够喝一壶。更别提 Node 冷启动那动辄几百毫秒的 V8 初始化开销。

Bun 的野心很直接：用单个二进制，把运行时、包管理器、打包器、测试 runner、转译器全部吞掉。它不是「又一个 Node 替代品」，而是一次对前端/Node 工具链交付方式的重新设计。本文不喊口号，从内核选型、架构实现，到能直接上生产的代码，把 Bun 掰开揉碎讲清楚。

一、背景：我们为什么受够了 Node 的「工具链恐怖主义」

先说一个真实到扎心的场景。你 git clone 一个中等规模的 TypeScript 全栈仓库，接下来会发生什么？

1. npm install 或 pnpm install —— 解析依赖树、去重、写 node_modules，大项目动辄几十秒到几分钟；
2. tsc --noEmit 做类型检查，再 esbuild 打包，或 webpack 走一遍插件链；
3. jest/vitest 起一个独立的转译 + 执行环境跑测试；
4. nodemon 监听文件变化重启进程；
5. 上线前 prettier --check 再扫一遍格式。

注意：这五步里，有至少四种不同的转译器、三套模块解析逻辑、两套测试运行时。它们各自维护一份配置，各自对 ES 规范的理解有细微偏差，于是你无数次遇到「本地能跑、CI 挂了」「dev 能跑、build 炸了」的诡异问题。

更致命的是隐性成本。显性成本是那几分钟安装、几十秒打包；隐性成本是「为了让这五个工具和睦相处，你不得不花掉的认知带宽」。一个新同事入职，第一周不是在理解业务，而是在理解 tsconfig.json 为什么和 babel.config.js 的 target 对不上、jest 的 transform 和 webpack 的 loader 为什么各转一遍、为什么 pnpm 装的包 webpack 解析不到。这些「配置考古」不写进任何需求文档，却真实吞噬着团队的吞吐量。

社区不是没尝试过收敛。Yarn PnP 想消灭 node_modules，Turborepo 想统一任务编排，Vite 想用 esbuild 把打包从构建期挪到浏览器——但这些都只是在「已有碎片」上打补丁，没有一个人从运行时层面重新定义「什么是 JS 项目的最小交付单元」。Bun 的激进之处正在于此：它不试图协调那些工具，而是把它们的能力重新实现一遍，然后塞进同一个二进制。「协调」失败了二十年，「重写」反而成了最短路径。

Node 本身的设计哲学是「运行时只管运行时」，工具链交给社区拼装。这在 2010 年代是优点——生态自由生长；但在 2020 年代成了负担——认知成本和构建时间被无限摊薄。

Bun 的创始人 Jarred Sumner 在 2021 年启动这个项目时，目标就是：让 bun install 比 npm install 快一个数量级，让 bun run、bun test、bun build 都是同一个引擎在说话，而不是五个互相不认识的进程。

这就是 Bun 出现的根本原因，不是「又造了个轮子」，而是「把五个轮子焊成了一个」。

二、核心概念：Bun 到底是什么，又凭什么快

2.1 三层心智模型

别把 Bun 想成一个运行时就完了。它其实是三层叠加：

┌─────────────────────────────────────────────┐
│  3. 标准 Web API + Bun.* 扩展全局对象          │
│     fetch / Response / WebSocket / Bun.serve  │
│     Bun.file / Bun.sql / Bun.spawn ...        │
├─────────────────────────────────────────────┤
│  2. 工具链（同一二进制内置）                   │
│     bun install  bun test  bun build  bun run │
├─────────────────────────────────────────────┤
│  1. 运行时内核                                  │
│     Zig 实现 + JavaScriptCore 引擎            │
└─────────────────────────────────────────────┘

• 第一层（内核）：一个 Node.js 兼容的 JavaScript 运行时，几乎零改动跑你的 server.js。
• 第二层（工具链）：bun install、bun test、bun build、bun run 全部是 Bun 这个二进制自带的子命令，不再依赖 npm/jest/webpack。
• 第三层（API）：既实现了 Web 标准 API（fetch、Response、WebSocket、TextEncoder…），又提供了 Bun.* 这组 Node 没有的高性能扩展。

2.2 为什么是 JavaScriptCore，而不是 V8

这是 Bun 最关键、也最容易被误解的选型。Node 用 V8，Deno 也用 V8，但 Bun 选了 WebKit 的 JavaScriptCore（JSC）。

差异在哪？

• 冷启动：V8 为了峰值性能，启动时要做较多初始化（比如提前编译内置函数、生成优化代码骨架）。JSC 走的是「LLInt（低级解释器）→ 基线 JIT → DFG/FTL JIT」的渐进式路径，第一条指令执行前几乎零成本，特别适合 CLI、serverless、短生命周期脚本这种「启动即峰值」的场景。
• 内存占用：JSC 的常驻内存通常比 V8 轻，对容器化部署更友好。
• 嵌入友好：JSC 的 C API 相对干净，适合被 Zig 这种系统语言直接包裹。

当然，JSC 的峰值吞吐在超长运行的计算密集型任务上未必能赢 V8 的 TurboFan。但 Bun 瞄准的主力场景——Web 服务、脚本、工具——恰恰更吃启动和内存，JSC 在这里是更优解。

2.3 为什么用 Zig 写

Bun 的主体实现语言是 Zig，而不是 C++ 或 Rust。原因很务实：

1. 和 C/C++ 生态零摩擦互操作：JSC 本身是 C++ 代码库，Zig 能直接 @cImport 调用 C 头文件，不需要写一堆胶水层；
2. 没有隐藏的分配器和 GC：Zig 手动管理内存，Bun 可以在 JSC 的 GC 节拍之外精确控制分配，避免两个 GC 互相打架；
3. comptime（编译期计算）：Bun 用 Zig 的 comptime 大量生成转译器、哈希表、HTTP 解析器等 boilerplate，既快又省；
4. 无运行时依赖：编译出来基本是静态二进制，分发简单。

一句话：Zig 给了 Bun 把 C++ 引擎和现代语言体验焊在一起的能力，这是用 Rust 或纯 C++ 都更难优雅达成的。

举个具体的例子，Zig 的 comptime 允许在编译期执行代码并生成类型。Bun 的转译器里大量用到这种模式——比如根据不同的 target（browser / node / bun）和 loader（ts / tsx / jsx），在编译期生成对应的词法分析分支，而不是在运行时做一堆 if-else 分支判断。结果是运行时路径更短、分支预测更友好。这种「把能确定的事在编译期做完」的范式，正是 Bun 能在一个二进制里塞下整个工具链却不失速的关键。当然，Zig 也有代价：生态小、编译器本身还在快速演进、招人难。Bun 团队敢押注 Zig，某种程度上也是因为他们的核心诉求（贴近 C、零运行时依赖、极致控制内存）和 Zig 的设计目标高度重合。

2.4 Node 兼容：真的能「零改动」吗

Bun 实现了 Node 绝大多数内置模块：fs、path、http、stream、Buffer、process、crypto、child_process… 同时支持 N-API（Node 原生插件的稳定 ABI），所以很多 .node 原生模块能直接加载。

这意味着你手里那堆 require('express')、import { readFile } from 'fs/promises' 的代码，在绝大多数情况下 bun server.js 就能直接跑，不用改一行。当然，Node 的每一个边界行为 Bun 都还没 100% 对齐（后面性能章节会讲坑），但「drop-in」在 80% 的项目上成立。

2.5 Bun vs Deno vs Node：三个 runtime 的本质分野

讲到这里，有必要把 Bun 和它的「同类」摆在一起看，因为很多人把它们混为一谈，其实三者赌的是完全不同的方向：

• Node.js：赌「生态即护城河」。V8 + libuv 的组合稳了十几年，几乎所有 npm 包都围绕它的行为约定构建。它的强项是「你能想到的库都有」，弱项是工具链碎、启动慢、历史包袱重。
• Deno：赌「安全与标准」。同样用 V8，默认沙箱权限、原生 TypeScript 支持、强调 Web 标准 API。它的强项是安全和现代 API 设计，弱项是生态体量远小于 Node，很多 npm 包要用 --compat 才能跑。
• Bun：赌「速度与一体化」。用 JSC，单二进制吞掉工具链，强项是快和「一个命令搞定一切」，弱项是 Windows 成熟度和对 Node 边界行为的 100% 对齐。

一句话记忆：Node 要的是「全」，Deno 要的是「正」，Bun 要的是「快」。选哪个，取决于你当下最痛的是生态缺口、安全合规，还是构建等待时间。对一个想快速验证想法、又不想被工具链拖垮的团队，Bun 的「快」往往是最直接可感知的红利。

三、架构分析：Bun 内部到底干了什么

3.1 转译器：从「运行时」变成「编译器」

Bun 最被低估的能力之一，是它内置了一个生产级转译器。它能原生理解 TypeScript、JSX、TSX，无需 tsc 或 babel 预处理。

原理：当你 import './util.ts' 时，Bun 在模块加载阶段就用内置转译器把 .ts 即时编译成 JS，再交给 JSC 执行。这个转译器用 Zig 写成，速度极快，且和 bun build 打包器共用同一套前端。

你可以直接在代码里用它：

// 用 Bun 的转译器 API 把一段 TS 代码转成 JS
const transpiler = new Bun.Transpiler({ target: "browser", loader: "ts" });

const tsSource = `
  const greet = (name: string): string => \`hello \${name}\`;
  export default greet;
`;

const jsSource = transpiler.transformSync(tsSource);
console.log(jsSource);
// 输出：const greet = (name) => \`hello \${name}\`; export default greet;

Bun.Transpiler 还支持 scan()（只做 import 分析，不执行，用来做依赖图）、transform() 异步版本等，可以做自定义构建工具。

3.2 模块解析与 bunfig

Bun 的模块解析是它「快」的另一个隐藏功臣。Node 的模块解析要一层层往上找 node_modules、读 package.json 的 exports/main 字段、处理 symlink，路径一长就慢。Bun 把解析结果和包元数据做了内存级缓存，并且把 package.json 的字段解析、条件导出（import/require/browser/bun）在加载入口时一次性算清楚。

这意味着第一次 import 某个深层依赖时可能还要走一遍解析，但同进程内后续解析几乎零成本。配合 bun install 写入的二进制锁文件，bun run 启动一条命令就能把「装依赖 → 解析 → 转译 → 执行」四步合成一步，这也是为什么 bun run 给人的体感是「按完回车就起来了」。

# bunfig.toml
[install]
exact = true            # 不自动加 ^ 前缀
saveTextLockfile = false # 默认生成二进制 bun.lockb

[run]
preload = ["./instrument.ts"]  # 每个入口前预加载

[test]
preload = ["./test-setup.ts"]

bun.lockb 是二进制锁文件，比 package-lock.json 解析快得多，也更省空间——这是 bun install 快的一个重要原因。

Bun 的模块解析遵循 Node 的规则，但会在 bunfig.toml 里支持额外配置：

# bunfig.toml
[install]
exact = true            # 不自动加 ^ 前缀
saveTextLockfile = false # 默认生成二进制 bun.lockb

[run]
preload = ["./instrument.ts"]  # 每个入口前预加载

[test]
preload = ["./test-setup.ts"]

bun.lockb 是二进制锁文件，比 package-lock.json 解析快得多，也更省空间——这是 bun install 快的一个重要原因。

3.3 HTTP 服务：Bun.serve 的网络栈

Bun.serve 是 Bun 的 HTTP 服务入口，底层是一个高度优化的联网层（实现上借鉴了 uWebSockets 的思路，零拷贝处理 socket）。它最舒服的一点是handler 直接返回 Web 标准的 Response：

Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("Hello from Bun!");
  },
});

这意味着你写的 handler 和浏览器里的 fetch、Service Worker、Cloudflare Workers 是同一套心智模型，代码可移植性极强。

更深一层看，这个设计背后是 Bun 对「Web 标准」的押注：它认为未来所有 JS 运行环境（浏览器、边缘、服务端、Worker）都会收敛到 Request/Response/fetch 这套契约。所以 Bun 没有发明自己的路由对象或上下文封装，而是直接把 Web 标准搬进来。带来的好处是你的业务逻辑不绑定任何框架——同一段 fetch(req) 既能在 Bun 跑，也能贴进 Cloudflare Worker 跑，迁移成本趋近于零。这也是为什么 Bun 生态里能长出 Hono、Elysia 这类框架：底座够标准，框架只需要做薄薄的路由糖，而不是重新发明一套请求生命周期。对比 Express 那套 (req, res) 回调 + res.end() 的老范式，Web 标准模型把「响应是一个值」这件事说清楚了，组合性和测试性都更好。

3.4 SQLite 内建：Bun.sql

Bun 直接内置了 SQLite（通过 libSQL），提供 Bun.sql 接口。注意它不是 ORM，而是一个带类型推导的 tag template 客户端：

const db = Bun.sql({
  url: "file:./app.db",
});

// 参数化查询：用模板字符串的插值自动转义，避免 SQL 注入
const users = await db`SELECT * FROM users WHERE age > ${18}`;

这个设计妙在：你写的是原生 SQL，但插值部分由 Bun 负责安全地参数化，既保留 SQL 的表达力，又不掉进字符串拼接注入的坑。

3.5 Bun 全局对象速查

把常用的 Bun.* 一次列清，后面代码实战会逐个用上：

四、代码实战：从 hello world 到生产级服务

下面所有示例都能直接 bun run xxx.ts 执行，不需要任何额外依赖。

4.1 安装与第一个服务

# 安装 Bun（macOS / Linux）
curl -fsSL https://bun.sh/install | bash

# 验证
bun --version   # 1.x

# 建项目
mkdir bun-demo && cd bun-demo
bun init        # 生成 package.json + index.ts

最小服务 server.ts：

const server = Bun.serve({
  port: 3000,
  fetch(req) {
    const url = new URL(req.url);
    if (url.pathname === "/") {
      return new Response("Hello from Bun! 🚀");
    }
    return new Response("Not Found", { status: 404 });
  },
});

console.log(`Listening on http://localhost:${server.port}`);

bun run server.ts

4.2 生产级 HTTP 服务：路由 + 中间件 + 流式 + WebSocket

真实服务不可能只有一个 if。下面给出一个带路由表、中间件链、流式响应、WebSocket 的完整骨架：

// router.ts
type Handler = (req: Request, ctx: Ctx) => Response | Promise<Response>;
interface Ctx { params: Record<string, string>; }

// 极简路由（生产可换 hono / elysia，但原理一致）
const routes: { method: string; pattern: RegExp; keys: string[]; handler: Handler }[] = [];

function route(method: string, path: string, handler: Handler) {
  const keys: string[] = [];
  const pattern = new RegExp(
    "^" + path.replace(/:(\w+)/g, (_, k) => { keys.push(k); return "([^/]+)"; }) + "$"
  );
  routes.push({ method, pattern, keys, handler });
}

function match(method: string, pathname: string) {
  for (const r of routes) {
    if (r.method !== method) continue;
    const m = r.pattern.exec(pathname);
    if (!m) continue;
    const params: Record<string, string> = {};
    r.keys.forEach((k, i) => (params[k] = m[i + 1]));
    return { handler: r.handler, params };
  }
  return null;
}

// 中间件：统一计时 + CORS
async function withTiming(next: Handler, req: Request, ctx: Ctx) {
  const t0 = performance.now();
  const res = await next(req, ctx);
  const t1 = performance.now();
  res.headers.set("X-Response-Time", `${t1 - t0}ms`);
  return res;
}

function cors(res: Response) {
  res.headers.set("Access-Control-Allow-Origin", "*");
  return res;
}

route("GET", "/users/:id", async (req, ctx) => {
  // 模拟查库
  return Response.json({ id: ctx.params.id, name: "Ada" });
});

route("GET", "/stream", async () => {
  // 流式响应：Server-Sent Events 风格
  const stream = new ReadableStream({
    start(controller) {
      let i = 0;
      const timer = setInterval(() => {
        controller.enqueue(`data: tick ${i++}\n\n`);
        if (i >= 5) { clearInterval(timer); controller.close(); }
      }, 500);
    },
  });
  return new Response(stream, {
    headers: { "Content-Type": "text/event-stream" },
  });
});

Bun.serve({
  port: 3000,
  async fetch(req) {
    const url = new URL(req.url);
    const hit = match(req.method, url.pathname);
    if (!hit) return cors(new Response("Not Found", { status: 404 }));
    const res = await withTiming(hit.handler, req, { params: hit.params });
    return cors(res);
  },
  // WebSocket 升级
  websocket: {
    message(ws, msg) {
      ws.send(`echo: ${msg}`);
    },
    open(ws) { ws.send("connected"); },
  },
});

console.log("server up at :3000");

要点：

• handler 返回 Response，天然支持 Response.json()、流式 ReadableStream、自定义 header；
• 中间件就是高阶函数，和 Express/Koa 思路一致，但没有任何框架依赖；
• WebSocket 通过 Bun.serve 的 websocket 选项直接支持，零额外库。

4.3 文件 IO 与零拷贝

Bun 对文件操作做了大量优化，Bun.file + Bun.write 比 Node 的 fs 写法更短也更高效：

// 读取并原样返回（零拷贝，直接把文件当 Response body）
Bun.serve({
  port: 3000,
  fetch(req) {
    const url = new URL(req.url);
    if (url.pathname === "/logo") {
      // Bun.file 返回的 Blob 可直接作为 Response body
      return new Response(Bun.file("./public/logo.png"));
    }
    return new Response("ok");
  },
});

// 写文件：支持路径字符串、URL、Blob、ArrayBuffer、Response
await Bun.write("./out/a.txt", "hello");
await Bun.write("./out/b.txt", Bun.file("./src.txt"));   // 文件到文件
await Bun.write("./out/c.bin", new Uint8Array([1, 2, 3]));

// 高性能顺序写：用 stdout writer 做零拷贝输出
const writer = Bun.stdout.writer();
writer.write("line1\n");
writer.write("line2\n");
await writer.flush();

Bun.file() 返回的 BunFile 实现了 Blob 接口，所以可以直接塞进 Response 当下载/img 源，不需要把整个文件读进内存。

4.4 SQLite：Bun.sql 实战

const db = Bun.sql("file:./app.db");

// 建表
await db`CREATE TABLE IF NOT EXISTS posts (
  id INTEGER PRIMARY KEY AUTOINCREMENT,
  title TEXT NOT NULL,
  views INTEGER DEFAULT 0,
  created_at TEXT DEFAULT (datetime('now'))
)`;

// 插入（插值自动参数化）
const title = "Bun 真香";
await db`INSERT INTO posts (title) VALUES (${title})`;

// 批量插入
const rows = [
  { title: "A", views: 10 },
  { title: "B", views: 20 },
];
for (const r of rows) {
  await db`INSERT INTO posts (title, views) VALUES (${r.title}, ${r.views})`;
}

// 查询 + 类型安全
const hot = await db`SELECT * FROM posts WHERE views > ${5} ORDER BY views DESC`;
console.log(hot); // 数组，元素为普通对象

// 事务：用 sql.begin
const result = await db.begin(async (tx) => {
  await tx`UPDATE posts SET views = views + 1 WHERE id = 1`;
  await tx`INSERT INTO posts (title) VALUES (${"tx-demo"})`;
  // 抛错会自动回滚
  return "done";
});

// 用完关闭
await db.close();

坑提醒：Bun.sql 默认是单连接。高并发 Web 服务里，建议每个请求用 db 的同一实例（Bun 内部有连接池封装），或显式用 db.transaction()/db.begin() 隔离写操作。

4.5 bun install 提速实战

bun install 快的三个原因：

1. 并行解析 + 全局缓存：依赖下载到 ~/.bun/install/cache，多项目共享，重复包不重复下载；
2. 二进制锁文件 bun.lockb 解析飞快；
3. 跳过 postinstall 的默认安全策略（需要时用 bun install -y 或配置允许）。

# 对比实验：同一项目
time npm install     # 往往 30s+
time bun install     # 往往 1~3s（视网络与缓存）

# 工作区（monorepo）
bun install          # 自动识别根 package.json 的 workspaces 字段

实测经验值：在已有全局缓存的情况下，bun install 比 npm install 快 10~30 倍；首次冷装受网络瓶颈限制，差距会缩小，但解析阶段依然明显更快。

4.6 bun test：自带测试 runner

// math.test.ts
import { expect, describe, it, beforeAll } from "bun:test";

function add(a: number, b: number) { return a + b; }

describe("add", () => {
  beforeAll(() => console.log("setup"));

  it("adds two numbers", () => {
    expect(add(1, 2)).toBe(3);
  });

  it("is commutative", () => {
    expect(add(2, 3)).toEqual(add(3, 2));
  });

  it.todo("handle bigint");
});

bun test                 # 跑全部
bun test math.test.ts    # 单个文件
bun test --watch         # 监听模式

bun:test 的 expect 语法和 Jest 高度兼容，迁移成本极低；而且它在同一个运行时内转译执行，不需要像 Jest 那样起 worker + 转译子进程，启动快得离谱。

4.7 bun build：API 化打包

bun build 不只是 CLI，更是可编程的 API，适合写自定义构建脚本：

// build.ts
const result = await Bun.build({
  entrypoints: ["./src/index.ts", "./src/admin.ts"],
  outdir: "./dist",
  target: "browser",      // 或 "node"
  format: "esm",          // 或 "cjs" / "iife"
  minify: true,
  splitting: true,        // 代码分割
  sourcemap: "external",  // 生成 .map
  naming: "[dir]/[name].[hash].js",
  external: ["react"],    // 标记为外部依赖
});

if (!result.success) {
  for (const log of result.logs) console.error(log);
  throw new AggregateError(result.logs, "build failed");
}

console.log(result.outputs.map((o) => o.path));

4.8 子进程：Bun.spawn

// 同步等待子进程，拿 stdout
const proc = Bun.spawn(["ls", "-la"], { stdout: "pipe" });
const text = await new Response(proc.stdout).text();
console.log(text);

// 管道串联：ps | grep bun
const ps = Bun.spawn(["ps", "aux"], { stdout: "pipe" });
const grep = Bun.spawn(["grep", "bun"], { stdin: ps.stdout, stdout: "pipe" });
const out = await new Response(grep.stdout).text();

Bun.spawn 返回的对象自带 stdout/stderr（可直接当流读）、exited（Promise）、kill() 等方法，比 Node 的 child_process 用起来顺手得多。

五、性能优化与真实取舍

5.1 几个有代表性的对照（注意：数字随硬件/场景浮动，下面是量级参考）

重要：这些数字不是给你拿去吹牛的，而是给你建立「什么时候该考虑 Bun」的直觉。Bun 在启动敏感型负载（CLI、serverless、CI 脚本、测试）上收益最大；在长连接、重计算负载上，和 Node 差距会收窄。

5.2 什么时候该用 Bun

• ✅ CLI 工具 / 脚本：启动快、单文件分发、内置 SQLite，写个内网小工具爽到飞起；
• ✅ Monorepo 的 install/test/build：bun install 和 bun test 的提速在大型仓库里体感爆炸；
• ✅ SSR / 边缘渲染：Bun.serve + Web 标准 API，和边缘运行时同构；
• ✅ 新建轻量服务：用 Bun.serve + Bun.sql 起内部系统、原型、后台任务。

5.3 什么时候先别急着重写

• ⚠️ 重度依赖原生模块的项目：虽然 N-API 兼容，但一些靠 Node 私有 API 的老 .node 模块可能跑不起来，需要 rebuild；
• ⚠️ Windows 生产环境：Bun 对 Windows 的支持在快速成熟，但生产级稳定性建议再观望几个小版本；
• ⚠️ 极致兼容性要求：银行和强监管系统往往要求「和 Node 字节级一致」，Bun 的边界行为差异可能成为审计风险；
• ⚠️ 已经用 Node 跑得很稳的核心服务：迁移有成本，先用 Bun 跑工具链（install/test/build），运行时维持 Node，是更稳妥的渐进策略。

5.4 常见坑与对策

5.5 性能调优 checklist

1. 先换 bun install：零风险，立刻省时间；
2. 用 Bun.file 当静态资源源，别把文件读进 Buffer 再返回；
3. Streaming 优先：大响应用 ReadableStream，降低内存峰值；
4. bun build 开 splitting + minify，生产产物更小；
5. profiling：bun --inspect 然后 Chrome DevTools 连 ws://localhost:6499 看 CPU/堆快照；
6. 别滥用 Bun.sql 单连接做并发写，用 begin/连接池隔离。

5.6 一个真实的渐进迁移剧本

别一上来就「全量换成 Bun」。我们见过最稳的落地路径是这样的：

1. 第 0 周：只换 bun install 替换 npm install。零业务风险，CI 时间立刻腰斩，团队建立信任；
2. 第 2 周：引入 bun test，把 jest 配置平移过去（bun:test 的 expect 近乎兼容），本地测试循环从「泡杯咖啡」变成「秒回」；
3. 第 4 周：新写的内部脚本 / CLI 用 Bun.serve + Bun.sql，享受单二进制 + 内建数据库；
4. 第 8 周：挑一个非核心的边缘服务，运行时也切到 Bun，灰度观察内存和错误率；
5. 核心交易链路：继续跑 Node，直到 Bun 在该语言版本上跑满一个季度无事故再考虑。

这条路的精髓是「让收益先兑现，让风险后暴露」。你每动一步都能拿到可度量的提速，却始终保留退回 Node 的退路。

5.7 关于「快」的清醒认知

最后泼一盆冷水：Bun 的「快」是真实的，但不是免费的万能药。它解决的是工具链与启动这一类开销，而不是你的算法复杂度、数据库慢查询、或架构设计缺陷。如果你的接口要 2 秒是因为一条没加索引的 SELECT，换成 Bun 也救不了你——它最多把那 2 秒里头的几十毫秒启动开销省掉。所以把 Bun 当成「免费的启动和构建加速」来用最划算，当成「性能银弹」来用会失望。

六、总结展望：Bun 的赌注与你的决策

Bun 押注的是一件事：开发者不该为了「把 TS 跑起来」而维护五套互相猜疑的工具。它用 Zig 把 JavaScriptCore 包成一个既快又全的二进制，把运行时、包管理、打包、测试、转译全部收编。

从工程现实看，Bun 已经过了「玩具」阶段：bun install 在大量团队的生产 CI 里稳定提速，Bun.serve 扛住了不少中小型服务的真实流量，Bun.sql 让「进程内数据库」变得唾手可得。它的短板也很明确——Windows 生产成熟度、个别 Node 边界行为差异、超大型原生依赖生态的兼容。

给不同读者的建议：

• 如果你是独立开发者 / 创业团队：新项目直接上 Bun 全栈，省下的工具链心智可以拿去想业务；
• 如果你是大型团队的基础设施负责人：先让 Bun 接管 install/test/build（低风险高收益），运行时层按服务逐个灰度；
• 如果你是纯 Node 老项目维护者：不必急着重写，把 bun test 当免费加速器先吃起来。

还值得一提的是招聘与团队成本。一个新人理解 Bun 的心智模型，远比理解「五套工具的协作契约」容易——他只需要知道 bun run 会装、会转、会跑，不需要精通 tsconfig 的 moduleResolution 和 webpack 的 resolve.alias 为什么经常打架。在「招人越来越难、工具越来越碎」的当下，降低团队的工具认知负担，本身就是一种工程生产力。这不是玄学，而是把「隐形的协作摩擦」变成「单一的、可预测的命令行」。

最后一句实在话：技术选型没有银弹。Bun 的价值不在「取代 Node」，而在于把被工具链偷走的时间和注意力还给你。当 bun run 一个命令就能 install + test + build + serve 时，你才会意识到，原来我们过去浪费在等工具上的时间，比想象中多得多。

延伸阅读：Bun 官方文档 bun.sh/docs、GitHub oven-sh/bun 的 COMPATIBILITY.md、以及 bunfig.toml 的字段说明。动手跑一遍本文的 server.ts 和 Bun.sql 示例，比看十篇文章都管用。

本文代码示例在 Bun 1.x 下均可直接运行；性能数字为量级参考，请以你自己的机器实测为准。