别被营销号误导了！你以为真的 Bun 和 Deno 比 Node.js 快很多吗？

前言

很多人想学习一个服务端的 Javascript 技术，为了速度，或者为了时髦，开始抛弃 Node.js, 转而学习 Bun 或者 Deno, 但是我想告诉你的是，学习没有什么问题，但是真用在生产环境，请看完这篇文章。

我们先看一张 Bun 官网的一张图：

我们先来了解一个指标：QPS。它是一个直观反映系统处理能力 和吞吐量 的关键指标： HTTP requests per second ，通常缩写为 RPS 或 QPS ，中文是 "每秒HTTP请求数" 。

简而言之，Bun 的 QPS 是 Node.js 的 3 倍，是 Deno 的 2 倍。这里面我一直以来，我就很疑惑两个事

其一，Node.js 底层是用 C++ 写的，Bun 底层是 Zig，Deno 底层是 Rust。
- C++ 已经算是性能很好的了，凭什么 Zig 和 Rust 比 C++ 强这么多？
其二，Bun 使用的 Javascript 引起是 JavascriptCore， Node.js 使用的是 V8 引擎，不是号称 V8 是最好的，这也没体现出来来，真要快这么多，为什么 Electron 不内置 JavascriptCore 而是还是用 V8 引擎呢？

看来一些文章，以下的内容或许能解答这些疑惑！

语言构成与执行效率

Bun 与 Node.js 在语言架构上存在显著差异。Bun 主要由 Zig（61%）和 C++（23%）编写，JavaScript/TypeScript 仅占 11%；而 Node.js 的代码中 JavaScript 占比高达 62%，C++ 和 C 分别占 22% 与 2.7%。即便是 Deno，其 Rust 与 JavaScript/TypeScript 的比例也接近 1:1。

这种语言构成直接影响执行性能。由于 Bun 的核心逻辑更多由 Zig 和 C++ 实现，而 Node.js 的核心仍大量依赖 JavaScript，因此在系统级操作上 Bun 具备先天速度优势。若 Node.js 将更多核心逻辑迁移至 C++，两者之间的性能差距有望缩小。

JavaScript 引擎对比

实际上 JavaScriptCore（JSC）在很多情况下，性能并不如 V8。仅在某些特定操作（如 JSON 序列化与反序列化）中表现更优。V8 在正则表达式、JIT 编译、内存管理与解释器优化等方面均优于 JSC。

因此，当项目中 JavaScript 代码比重增加时，Bun 因 Zig 带来的性能优势会逐渐被 JSC 的 JavaScript 执行效率所抵消。对于大型 JavaScript 项目，Node.js 的性能往往与 Bun 相当，甚至反超。

HTTP 性能与基准测试分析

Bun 使用 uWebSockets（C++ 实现）作为其 HTTP 服务器基础，因此在某些基准测试中表现出比 Node.js 原生 HTTP 模块更高的吞吐量。然而，若在 Node.js 中也集成 uWebSockets，其性能也会成倍提高！

简单的总结

可总结如下：

Bun 在异步 I/O 操作上速度更快，主要得益于 Zig 的高效实现；但在 JavaScript 密集型任务中，受限于 JSC 的执行效率，其优势会减弱甚至消失。
- 也就是很多时候我们以来大量 javascript 第三方库的时候，上面的 QPS 测试数据很可能有非常大的变化。
在文件读写、系统调用等底层操作中，Bun 表现更优，因其实现大多位于 Zig 层；Node.js 的异步操作虽也基于 C++，但架构历史较长，优化空间有限。
对于中大型项目，Bun 的性能优势往往不明显，尤其在引入数据库访问与复杂业务逻辑后，其表现可能不及 Node.js。
V8 的 JIT 编译与整体优化水平高于 JSC。Bun 选用 JSC 而非 V8，可能导致其 Zig 与 C++ 的底层优化被 JavaScript 执行效率所拖累，仅在轻量场景中表现优异。
Deno 在架构上取得较好平衡：近半数核心由 Rust 编写，同时使用 V8 引擎，兼具高性能底层操作与高效的 JavaScript 执行能力，因此在复杂场景中常优于 Node.js。