Bun：想要让 Node 退休的运行时（现在有资金来实现这个目标了）

没人预料到的新闻

上周，当你我还在安静地与 node_modules 搏斗时，Anthropic 丢出了一颗炸弹：他们收购了 Bun。

是的，Claude 背后的公司决定他们的未来要依靠一个用 Zig 编写的 JavaScript 运行时，这是一个想着"要是 Node，但是快"的家伙写的。Claude Code 刚刚达到 10 亿美元的收入，显然当你有多余的钱时，第一件事就是购买开发工具。

为什么？因为 Claude Code 疯狂执行 JavaScript，当你有数百万用户时，每一毫秒都很重要。通俗地说：如果你的业务依赖于快速执行代码，你就买最快的运行时。

但够了企业八卦。让我们来看你感兴趣的：什么是 Bun，为什么你应该关心。

什么是 Bun（对于我们这些来自 Node 的人）

Bun 就像有人看着 Node 生态系统说：“要是我们做一个工具来替换这十五个工具会怎样？”

之前你有：

node          → 运行时
npm/pnpm/yarn → 包管理器
webpack/esbuild/vite → 打包器
jest/vitest   → 测试运行器
ts-node/tsx   → 执行 TypeScript

现在你有：

bun           → 以上所有功能

这是电动滑板车对比拖着拖车的汽车。更少的部件，更少可能出错的东西，奇怪的是还更快。

重要的数字

我不喜欢做基准测试，因为总是可以被操纵。但这些数字太残酷了，值得一提：

操作	Node + pnpm	Bun	差异
`install`（中等项目）	~25s	~3s	快 8 倍
运行时启动	~50ms	~5ms	快 10 倍
执行测试	基线	快 2-3 倍	明显
转译 TypeScript	需要工具	原生支持	∞

为什么这么快？因为它用 Zig 而不是 C++ 编写，因为 Jarred Sumner（创造者）是那种把优化代码当作兴趣爱好的程序员。这家伙在 Stripe 工作，决定世界上最重要的问题是 npm install 花费太长时间。

而且，嘿，也许他是对的。

已经可以工作的（和不能的）

Bun 与大多数 Node API 兼容。如果你的代码使用 fs、path、http 或任何标准模块，可能无需更改就能工作。

工作良好

Next.js：官方支持。bun run dev 就完了。
Express/Fastify：没问题。
大多数 npm 包：Bun 像 Node 一样读取 package.json 和 node_modules。
TypeScript：原生支持，无需配置。
JSX：也是原生支持。

可能有问题

带有 Node 原生绑定的包：一些需要重新编译。
依赖 V8 特定奇怪行为的代码：Bun 使用 JavaScriptCore（Safari 的引擎）。
一些非常特定的 Node API：Workers，cluster 的某些部分。

不工作（还没有）

Windows：能工作，但有一些限制。
Yarn PnP：不支持。

你的第一个 Bun 项目

如果你已经有 Node，安装 Bun 只需一个命令：

1
curl -fsSL https://bun.sh/install | bash

或者如果你使用 macOS 和 Homebrew：

1
brew install oven-sh/bun/bun

验证它是否工作：

1
bun --version

创建新项目

1
2
mkdir mi-proyecto && cd mi-proyecto
bun init

这会为你生成一个 package.json、一个 tsconfig.json 和一个 index.ts。没有问题，没有向导。这是我喜欢的方式。

生成的文件

1
2
// index.ts
console.log("Hello via Bun!");

执行它：

1
bun run index.ts

是的，直接执行 TypeScript。无需转译。无需 ts-node。什么都不需要。

从 pnpm 迁移

如果你有一个使用 pnpm 的项目，迁移出奇地简单：

1
2
3
4
5
6
# 选项1：重新生成锁文件
rm -rf node_modules pnpm-lock.yaml
bun install

# 选项2：使用现有锁文件（实验性）
bun install

Bun 生成自己的 bun.lockb（二进制，解析更快）。如果你在团队中工作且不是所有人都迁移了，可以在过渡期间保持两个锁文件。

package.json 不变

1
2
3
4
5
6
7
{
  "scripts": {
    "dev": "next dev",
    "build": "next build",
    "test": "vitest"
  }
}

你仍然执行 bun run dev、bun run build、bun run test。脚本工作方式相同。

测试：从 Vitest 到 Bun

Bun 有自己的测试运行器，与 Jest/Vitest API 兼容：

1
2
3
4
5
6
7
// sum.test.ts
import { expect, test } from "bun:test";
import { sum } from "./sum";

test("2 + 2 = 4", () => {
  expect(sum(2, 2)).toBe(4);
});

执行：

1
bun test

要是我想继续使用 Vitest 呢？

完全没问题。Bun 可以作为运行时执行 Vitest：

1
bun run vitest

你获得了 Bun 的启动速度和 Vitest 的功能。两个世界的最好结合。

你见过的最快的 HTTP 服务器

Bun 包含一个让 Express 哭泣的 HTTP 服务器：

1
2
3
4
5
6
7
8
Bun.serve({
  port: 3000,
  fetch(req) {
    return new Response("来自 Bun 的问候！");
  },
});

console.log("服务器运行在 http://localhost:3000");

它使用标准的 fetch API（Request/Response），所以如果你来自 Cloudflare Workers 或 Deno，会感觉像在家里一样。

Hello world 基准测试

在我的机器上（M1 Pro），一个 hello world 服务器：

Express：~15,000 req/s
Fastify：~45,000 req/s
Bun.serve：~150,000 req/s

是的，比 Express 快十倍。不，这不是打字错误。

环境变量

Bun 自动加载 .env。无需 dotenv。无需配置。

1
2
# .env
DATABASE_URL=postgres://localhost/mydb

1
2
// index.ts
console.log(Bun.env.DATABASE_URL);

就是这样。它就是工作。

集成的 SQLite

这让我大脑爆炸。Bun 自带集成的 SQLite：

1
2
3
4
5
6
7
8
import { Database } from "bun:sqlite";

const db = new Database("mydb.sqlite");
db.run("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)");
db.run("INSERT INTO users (name) VALUES (?)", ["Fernando"]);

const users = db.query("SELECT * FROM users").all();
console.log(users);

无需安装 better-sqlite3 或 sql.js。就是工作。

打包器

Bun 还可以为生产环境打包你的代码：

1
bun build ./index.ts --outdir ./dist

它比 esbuild 更快（esbuild 已经是疯狂快了）。对于大多数项目，生成等效的打包。

如果你需要更复杂的东西（代码分割，高级 tree shaking），你可能仍然需要 Vite 或 webpack。但对于许多情况，这就足够了。

何时不使用 Bun

因为并非一切都是彩虹和独角兽：

关键生产环境，你不能实验：Bun 是稳定的，但 Node 有 15 年的解决的 bug。
带有非常特定原生绑定的包：一些需要额外工作。
Windows 作为主要平台：能工作，但一流支持是针对 macOS/Linux。
你的团队不想学习新东西：有时最好的工具是每个人都知道如何使用的工具。

何时使用 Bun

CI/CD：减少的 install 时间节省真金白银。认真的，算算账。
脚本和内部工具：启动速度让脚本感觉瞬间完成。
没有遗留代码的新项目：用 Bun 开始比用 Node + npm + tsx + vitest + … 开始更简单
Serverless/Edge：更少启动时间 = 更少冷启动 = 更少延迟 = 更满意的用户。
现在 Anthropic 支持它：这不是小事。他们有钱，有动机，有一个依赖 Bun 优秀的产品（Claude Code）。

我的建议

如果你正在开始一个新项目并且没有团队限制，试试 Bun。最坏的情况是你回到 Node，而你会学到一些东西。

如果你有一个现有的生产项目，首先在 CI/CD 中评估。这是最明显差异的地方，风险也最小。如果 bun install 与你的依赖项工作良好，你就已经赢了。

如果你是那种喜欢生活在边缘的人，把它用到生产环境并告诉我怎么样。我还不敢，但我手指交叉。

资源

结论

Bun 是当有人看着 JavaScript 生态系统并决定我们可以做得更好时发生的事情。令人担忧的是…他是对的。

这是 Node 的终结吗？可能不是。Node 不会消失，就像 Java 在…嗯，任何东西出现时没有消失一样。但它确实是很长时间以来第一个认真的竞争者。

现在 Anthropic 在背后，带着他们的十亿美元和对 JavaScript 飞行的需求，事情变得有趣了。

与此同时，我将继续在生产环境中使用 pnpm。但我的本地脚本已经运行在 Bun 上，我的 CI 正在迁移过程中。一步一步来。

TL;DR：Bun 是一个 JavaScript 的一体化运行时（运行时 + 包管理器 + 打包器 + 测试运行器），比 Node 快得多。Anthropic 刚刚收购了它。与大多数现有的 TypeScript 项目兼容。首先在 CI 中试试，那是最明显的地方。

没人预料到的新闻#

什么是 Bun（对于我们这些来自 Node 的人）#

重要的数字#

已经可以工作的（和不能的）#

工作良好#

可能有问题#

不工作（还没有）#

你的第一个 Bun 项目#

创建新项目#

生成的文件#

从 pnpm 迁移#

package.json 不变#

测试：从 Vitest 到 Bun#

要是我想继续使用 Vitest 呢？#

你见过的最快的 HTTP 服务器#

Hello world 基准测试#

环境变量#

集成的 SQLite#

打包器#

何时不使用 Bun#

何时使用 Bun#

我的建议#

资源#

结论#