Node.js、Bun 与 Deno：JavaScript 运行时横向对比

Node.js、Bun 和 Deno 都能执行 JavaScript，也都支持现代 Web 开发。它们的差异集中在运行时 API、模块加载方式、TypeScript 处理、包管理、内置工具链和权限模型。

本文把三者放在同一张技术坐标系中比较，帮助你根据项目生态、开发体验和部署环境做选择。本文关注能力边界与使用方式，具体版本的行为仍应以对应版本的官方文档为准。

先区分运行时、包管理器和框架

运行时负责加载并执行 JavaScript 或 TypeScript，提供文件、网络、进程、定时器和模块系统等宿主能力。包管理器负责解析依赖、下载软件包和生成锁文件；框架负责组织 Web、服务端、桌面或命令行应用。

同一个项目可以使用 Node.js 运行代码、pnpm 管理依赖，再用 Astro 负责页面构建。Bun 将运行时、包管理器、测试工具和打包器放进同一个命令中；Deno 也提供一套内置工具链。

三者的定位

Node.js：生态兼容的默认基线

Node.js 基于 V8 引擎，长期服务于服务端、脚本、构建工具、CLI 和桌面应用生态。它同时支持 ECMAScript Modules 和 CommonJS，package.json、npm 包、node_modules、CI 工具和云平台形成了非常成熟的协作体系。

Node.js 适合以下场景：

• 项目依赖数量多，且依赖包含原生扩展或 Node.js 专用 API。
• 团队需要广泛的第三方库、托管平台和招聘市场支持。
• 生产环境已经确定使用 Node.js，需要降低迁移和兼容成本。
• 项目需要细致控制构建、测试和发布工具的组合。

现代 Node.js 已提供轻量的 TypeScript 类型擦除能力。它适合执行可以直接擦除类型的 TypeScript 语法；完整 TypeScript 转换、tsconfig.json 相关行为和更复杂的编译需求仍由 tsc、tsx 等工具承担。详情参见 Node.js TypeScript 文档。

Bun：一体化 JavaScript 工具链

Bun 使用 JavaScriptCore 引擎，运行时、包管理器、测试运行器和打包器由同一个可执行文件提供。Bun Runtime 官方文档说明了它对 JavaScript、TypeScript、JSX、package.json 脚本和 Node.js 兼容入口的支持。

Bun 适合以下场景：

• 新项目希望直接运行 TypeScript 和 JSX，并减少工具安装数量。
• 需要统一 bun install、bun test、bun build 和 bun run 的项目脚本。
• 团队愿意使用 Bun 的实现方式，并通过测试确认第三方依赖兼容性。
• 本地开发或 CI 对启动速度、安装速度和工具数量比较敏感。

Bun 持续实现 Node.js API，并提供兼容性清单。兼容性按模块和 API 分布，涉及 node:fs、原生扩展、诊断工具、测试 Mock 或特殊加载行为时，应以实际项目测试结果为准。

Deno：权限优先、TypeScript 优先的运行时

Deno 使用 V8，引入了显式权限模型、原生 TypeScript 支持、ES Modules、内置格式化、Lint、测试、覆盖率、基准测试和编译工具。Deno 官方入门文档将它定位为 JavaScript、TypeScript 和 WebAssembly 运行时。

Deno 适合以下场景：

• 脚本需要明确限制文件、网络、环境变量或子进程权限。
• 项目希望直接执行 TypeScript，并用 deno check 完成类型检查。
• 项目偏好 Web 标准、ES Modules 和一体化命令行工具。
• 新项目可以接受 Deno 的配置、缓存和依赖管理方式。

Deno 2 继续强化 Node.js 和 npm 兼容性，能够读取 package.json、使用 npm 包并运行许多既有 Node.js 项目。Node 和 npm 兼容性文档列出了 node: 模块、Node 全局变量、CommonJS、node_modules 和原生扩展的支持范围。

核心能力横向对比

表格中的“兼容”描述运行时提供的入口范围。它不等同于每个依赖在每种项目配置下都能直接运行，生产迁移仍需要执行项目自身的测试和构建。

常用命令对照

下面的命令用于展示入口差异，实际参数和配置仍按项目工具链调整：

Node.js 的 node app.ts 依赖当前 Node.js 版本的 TypeScript 支持范围；需要完整编译语义时，使用项目配置的 TypeScript 工具。Bun 和 Deno 都可以直接读取 TypeScript 文件，但执行 TypeScript 与类型检查仍是两个独立动作。

TypeScript 体验对比

Node.js：逐步增强的原生支持

Node.js 的内置 TypeScript 支持以类型擦除为核心：运行时移除类型标注，再执行生成的 JavaScript。它不读取完整的 tsconfig.json 行为，也不会自动完成所有需要生成 JavaScript 代码的 TypeScript 语法转换。

适合 Node.js 的常见流程是：

npm install
npx tsc --noEmit
npm test
npm run build

项目也可以使用 tsx、ts-node 或框架自带的构建工具，形成更完整的 TypeScript 开发体验。

Bun：运行时直接处理 TypeScript

Bun 的转译器会在执行前处理 TypeScript 和 JSX，常见开发入口可以直接使用 .ts 或 .tsx 文件：

bun run src/index.ts
bun test

Bun 的直接执行提高了启动便利性。类型正确性仍应交给 tsc --noEmit、编辑器或 CI 检查，运行时转译本身承担代码执行准备工作。

Deno：执行、检查和工具链一体化

Deno 将 TypeScript 视为一等输入格式，执行与类型检查分别由 deno run 和 deno check 负责：

deno run main.ts
deno check main.ts
deno test

Deno 项目可以将编译器选项写入 deno.json。从 Node.js 迁移时，已有 tsconfig.json 和 package.json 也能参与兼容流程；项目进入 Deno 原生模式后，推荐围绕 deno.json 组织配置。

模块和依赖管理

Node.js 的 package.json 路线

Node.js 项目通常以 package.json 声明依赖和脚本，npm、pnpm、Yarn 负责解析依赖并生成对应锁文件。Node.js 对 ESM 和 CommonJS 都提供成熟支持，库作者还可以通过 exports、imports 和条件导出描述不同环境的入口。

{
  "scripts": {
    "dev": "node src/index.js",
    "test": "node --test"
  }
}

Bun 的 npm 兼容和一体化命令

Bun 可以读取 package.json，使用 npm registry，并通过 bun install 安装依赖。它同时支持 CommonJS 和 ESM，项目可以逐步把脚本切换到 bun run，再根据测试结果启用 bun test 或 bun build。

bun install
bun run dev
bun test

Bun 提供多种依赖布局策略。现有项目应保留原有锁文件和 CI 行为，确认依赖解析结果后再决定是否迁移到 Bun 的锁文件与安装策略。参考 bun install 官方文档。

Deno 的 ES Modules、npm 和 JSR

Deno 原生偏好标准 ESM，可以直接使用文件扩展名、URL 导入、npm: 包说明符和 JSR 生态。Deno 也支持 package.json、CommonJS 和 node_modules，适合渐进迁移已有 Node.js 项目。

import chalk from 'npm:chalk@5';
import { readTextFile } from './config.ts';

使用 npm 依赖的 Deno 项目需要留意权限和安装模式。部分依赖读取本地文件、环境变量、网络或原生扩展时，要根据运行行为授予对应权限。

权限模型是 Deno 的重要差异

Deno 默认拒绝文件读取、文件写入、网络、环境变量和子进程等敏感操作，命令行通过 --allow-* 明确授权。授权可以细化到目录、域名或环境变量：

deno run --allow-net=api.example.com --allow-read=./data main.ts

Deno 安全与权限文档说明了权限的作用范围和限制。权限参数会成为运行命令的一部分，适合放在任务配置和部署脚本中审查。

Node.js 和 Bun 的常规使用方式更接近普通操作系统进程：程序启动后按照当前用户权限访问本地资源。需要更强隔离时，可以结合容器、操作系统账户、沙箱或云平台权限策略完成边界控制。

权限模型会影响迁移体验：一个 Node.js 项目在 Deno 中第一次访问网络或文件时，通常需要添加权限参数；一个依赖大量本地 I/O 的 CLI 也需要把权限声明纳入文档和测试。

Node.js 兼容性不能只看“能启动”

Bun 和 Deno 都提供 Node.js 兼容层，兼容性验证建议分成四层：

1. 模块层：检查 node:fs、node:http、node:worker_threads 等实际使用的模块。
2. 包层：检查依赖是否使用原生扩展、安装脚本、动态 require 或未声明的传递依赖。
3. 工具层：检查 CLI、测试运行器、Mock、覆盖率、调试器和打包器的行为。
4. 部署层：使用目标运行时执行完整构建、测试、启动、健康检查和退出流程。

Bun 官方维护了按 Node.js 模块划分的兼容性列表。Deno 官方文档也列出了 node: 模块、npm 包、CommonJS、Node 全局变量和原生 Node-API 扩展的支持条件。选择迁移时，把这两份清单与项目依赖树逐项对应。

性能应该这样比较

运行时性能由代码类型、依赖数量、启动参数、文件系统、网络、CPU、内存和运行平台共同决定。单个 Hello World 的启动时间可以说明一个局部特征，无法代表完整 Web 服务、构建任务或测试套件的生产表现。

更有价值的对比指标包括：

• 冷启动时间和首次请求延迟。
• 依赖安装时间、磁盘占用和缓存命中率。
• 开发服务器热更新速度。
• 完整测试套件的耗时和稳定性。
• 构建产物大小、内存峰值和长时间运行表现。
• 原生扩展、文件系统、网络和子进程场景的兼容程度。

基准测试应固定代码、依赖锁文件、机器、操作系统、运行参数和重复次数，并同时记录失败用例。团队最终需要的是可部署、可调试、可维护的性能结果。

如何选择

选择 Node.js

现有 Node.js 项目、企业服务、依赖复杂的全栈项目和需要最大生态覆盖的团队，优先使用 Node.js。它提供清晰的兼容基线，nvm、npm、pnpm、测试工具和云平台的协作资料也最丰富。

选择 Bun

新项目希望快速获得 TypeScript 执行、包管理、测试和打包能力时，可以优先评估 Bun。迁移已有 Node.js 项目时，先验证框架、原生扩展、安装脚本和测试工具，再把 Bun 固定到开发和 CI 环境。

选择 Deno

脚本安全边界、标准 ESM、TypeScript 原生体验和内置工具链是主要目标时，可以选择 Deno。需要运行大量 Node.js 生态依赖时，先验证权限、node_modules 模式、CommonJS 和原生扩展。

编写跨运行时库

面向多个运行时发布库时，优先依赖标准 JavaScript、Web API 和清晰的模块导出。运行时专属能力应放在适配层，并通过条件导出、能力检测和独立测试覆盖 Node.js、Bun、Deno 的差异。

nvm 与 Bun、Deno 的关系

nvm 专门管理 Node.js 版本：

nvm install 20
nvm use 20

Bun 和 Deno 使用自己的安装与升级方式。Bun 提供 bun upgrade，Deno 提供 deno upgrade；Deno 官方迁移文档明确区分了 deno upgrade 与 nvm 的多版本管理方式。

在同一台电脑上并行使用三者时，分别确认命令路径和 CI 镜像中的运行时版本：

command -v node
command -v bun
command -v deno

迁移建议

把现有 Node.js 项目迁移到 Bun 或 Deno 时，按下面顺序推进：

1. 保留原分支和锁文件，记录 Node.js 下的安装、测试、构建和启动结果。
2. 复制到独立分支，先尝试替换执行命令，再处理包管理和配置文件。
3. 检查原生扩展、postinstall、动态加载、CommonJS、路径别名和子进程调用。
4. 对比单元测试、集成测试、构建产物、启动日志和健康检查结果。
5. 在本地、CI、容器和生产环境统一运行时，记录版本和升级策略。

迁移可以分阶段完成：先用 Bun 或 Deno 执行测试，再替换开发命令，最后切换生产运行时。每个阶段都保留可回退的 Node.js 流程。

快速决策表

运行时选择可以先从项目约束出发：已有 Node.js 生态优先保持 Node.js；新项目需要一体化工具链时评估 Bun；安全权限和 TypeScript 原生体验占主导时评估 Deno。最终结论以项目测试、部署验证和团队维护能力为准。

参考文档

• Node.js TypeScript 文档
• Node.js Packages 文档
• Bun Runtime 文档
• Bun Node.js 兼容性
• Bun 安装依赖文档
• Deno TypeScript 文档
• Deno Node 和 npm 兼容性
• Deno 安全与权限
• Deno 从 Node.js 迁移