Node.js、Bun、Deno：2026 年选运行时，先承认 benchmark 会骗人

三个 JavaScript 运行时在 2026 年都可用于生产，这是好事，也让选择变难了。但大多数对比文章给出的 benchmark 有一个结构性问题：它们几乎都由运行时自己的团队发布，跑的是对自家有利的 workload，而你的 API 不是那个 workload。

把 benchmark 放一边之后，真正稳定的差异其实只有几项：生态深度、TypeScript 处理方式、开箱即用的工具链、安全模型、部署覆盖。

Node 的核心优势是“存量确定性”。所有托管平台都支持它，所有可观测性厂商都有它的 agent，冷门 npm 包只在它上面测过，凌晨出问题时最容易搜到现成答案。而且 Node 这些年补上了内置测试运行器、原生 ESM、watch 模式和权限模型，过去“你需要 Deno 才能做这个”的很多理由已经不再成立。它的代价是工具链需要自己组装：包管理器、打包器、转译器、测试运行器、linter 各配一套，升级节奏各自独立。

Bun 的卖点是单工具链和迭代速度。它直接跑 TypeScript，内置包管理器、测试运行器和打包器，本地开发和 CI 的体感提升是真实的。有基准显示 Bun 启动约 24ms、12K req/s，冷启动编译场景甚至能到 5ms 量级。但“快”和“生产放心”是两件事，生态里那些没有在 Bun 上验证过的边缘包，仍然是风险来源。

Deno 的差异化在安全模型：默认拒绝文件系统和网络访问，需要显式授权。对于安全敏感、或需要严格沙箱的执行环境，这个默认值本身就有价值。它同样原生支持 TypeScript，并内置测试和打包能力。

一个务实的结论：如果你要维护多年的核心服务、有合规要求、依赖原生模块，Node 仍然是默认答案；如果你追求本地迭代效率和单工具链，并且能接受对依赖做额外验证，Bun 值得在非核心链路上先跑；如果你需要严格权限边界或 Web 标准优先的运行时，Deno 是合理选择。三者的关系不是替代，而是按“生态风险容忍度”和“安全边界需求”分层。