Bun Docs与 Node.js、Deno 对比
从引擎、TypeScript、包管理、权限模型和部署形态选择运行时
最后更新于
先回答选型问题
三个运行时都能执行现代 JavaScript。差异不在“谁更快”，而在兼容边界、权限模型、包生态和部署形态。微基准排名不应进入选型依据；依赖树、部署平台和团队经验才应该。
能力对照
| 维度 | Bun | Node.js | Deno |
|---|---|---|---|
| JS 引擎 | JavaScriptCore | V8 | V8 |
| TypeScript 执行 | 原生，零配置 | 22.6+ 实验性；23.6 起默认支持可擦除语法，enum 等仍需 transform flag | 原生，零配置 |
| 类型检查 | 不管，交给 tsc | 不管，交给 tsc | 内置 deno check |
| 包管理 | bun install + 文本 bun.lock | npm + package-lock.json（或 pnpm/Yarn） | deno add + deno.lock；JSR 注册表与 npm: 说明符 |
node_modules | 需要 | 需要 | 默认不需要（全局缓存） |
| Node API 兼容 | 大量实现 node: API 与 Node-API，边界需实测 | 本体 | Deno 2 起支持大部分 node: / npm:，边界需实测 |
| 权限模型 | 无内建沙箱 | 实验性权限模型（--allow-fs-read 等） | 默认沙箱，显式 --allow-* / --deny-* |
| 测试 | bun test（Jest 风格） | node:test | deno test |
| 打包 | bun build | 无内建（esbuild/tsup 等） | 无内建 bundle（deno compile 面向可执行文件） |
| 单文件可执行 | bun build --compile | SEA（步骤较多） | deno compile |
易变行按一手资料复核
Node.js 的 TypeScript 支持、权限模型和 Deno 的 npm 兼容都在快速演进。本表核验于 2026-08-02；写进选型文档前查 Node.js 文档与 Deno 文档的当前版本。
决策路径
| 你的约束 | 倾向 |
|---|---|
| 新项目 CLI、内部服务，想要单工具链和原生 TS | Bun |
| 企业生产系统、重原生扩展、要求 LTS 与最大兼容面 | Node.js |
| 需要默认沙箱权限、URL import、少配置边缘脚本 | Deno |
| 目标是 Cloudflare Workers / Deno Deploy 等边缘平台 | 看平台运行时，不看本地偏好 |
| 已有大仓库 | 先按从 Node.js 迁移做并行验证，不做信仰切换 |
三个常见误判
- “Bun 兼容 Node 等于不用测”：原生扩展、边缘 loader、诊断工具行为都可能不同，逐项验证。
- “Deno 不能用 npm 包”：Deno 2 的
npm:兼容已覆盖多数常见包，但和 Bun 一样要测边界。 - “Node 跑不了 TypeScript”：新版 Node 已能直接执行可擦除类型语法；真正的问题是类型检查和生产构建仍要单独安排——这一点三个运行时一致。
对 Agent 的约束写法
Runtime: Bun 1.3.14. Do not suggest Deno permission flags or npm-only workflows.
If a dependency is documented Node-only or Deno-only, stop and report before migrating it.