JS 引擎全景图：这些引擎分别跑在哪些 Runtime 和产品里？

发布于 2026年05月05日 01:38 #DevOps

最近我在整理 AI 时代的基础设施赛道时，顺手又把 JS 引擎这条线捋了一遍。

越看越觉得，很多人平时聊 Bun、Deno、Cloudflare、React Native，其实都在聊同一件事，只是站的位置不同。

有人聊的是引擎，像 V8、JavaScriptCore、SpiderMonkey。有人聊的是 runtime，像 Node.js、Deno、Bun、Cloudflare Workers。还有人聊的是产品，像 Safari、Firefox、React Native、Moddable。

这三层经常被混在一起，但它们不是一回事。先把这个拆开，后面就顺了。

先说结论

如果你只想知道答案，我的结论很简单。

V8 仍然是最强势的通用底座，Node、Deno、Cloudflare Workers 都在它这条线上
JavaScriptCore 走的是另一条路，Safari 和 Bun 都把它变成了自己的核心选择
SpiderMonkey 更像 Firefox 生态里的老牌主心骨
Hermes、QuickJS、JerryScript、XS、MuJS、GraalJS 这些，则分别卡在移动端、嵌入式和 JVM 生态里

所以这篇文章真正想回答的，不是“JS 引擎有哪些”，而是“这些引擎到底落在了哪些实际产品里，以及为什么会这样”。

先把三层分清

我先用最短的话把它们拆开。

JS 引擎负责把 JavaScript 解析、编译、执行
Runtime 负责给这段 JavaScript 提供宿主环境，比如文件系统、网络、权限、事件循环、模块系统
产品是最终被开发者或用户接触到的东西，比如浏览器、移动框架、云函数平台、嵌入式 SDK

你可以把关系理解成这样。

引擎是发动机，runtime 是整车系统，产品是最终卖给你的车。

V8 本身不是 Node.js，JavaScriptCore 也不是 Safari。 Node.js、Deno、Bun、Cloudflare Workers 这些 runtime，才是真正把引擎包装成开发者每天会用的东西。

别小看这个区分。很多技术选型争论，表面上是在争引擎，实际上争的是 runtime、生态和默认体验。

先从最常见的三家说起

先说最广为人知的三家。

V8

V8 是 Google 的 JavaScript 和 WebAssembly 引擎，也是今天最有影响力的 JS 引擎之一。

它现在最典型的落点有几个。

Node.js
Deno
Cloudflare Workers
Chromium 系浏览器

这意味着什么。

如果你平时写 Node 或 Deno，大概率就是在 V8 上跑代码。Cloudflare Workers 虽然看起来像边缘平台，但它底层也是 V8 isolate 这一套。

V8 的意义不只是“快”，而是它已经变成了现代 JavaScript 生态最重要的底层事实之一。很多上层产品看起来不同，底层其实都踩在同一块地基上。

SpiderMonkey

SpiderMonkey 是 Mozilla 的 JavaScript 和 WebAssembly 引擎，最典型的使用方是 Firefox。

它的常见落点有。

Firefox
Servo
MongoDB 的 server-side JavaScript 路径（MongoDB 8.0 起已废弃）
CouchDB 的默认 JavaScript query server（CouchDB 3.4 起也提供 QuickJS 选项）

SpiderMonkey 的位置很有意思。

它不像 V8 那样在 server/runtime 世界里大规模扩散，但它在浏览器和 Mozilla 生态里仍然是核心引擎。MongoDB、CouchDB 这类数据库里的使用也更偏“内嵌脚本执行能力”，而且状态会随产品演进变化：MongoDB 已经开始弱化 server-side JavaScript，CouchDB 也在引入 QuickJS。对很多开发者来说，SpiderMonkey 更多是“浏览器兼容性的一部分”，而不是“自己会直接拿来嵌入的引擎”。

JavaScriptCore

JavaScriptCore 是 WebKit 的内置引擎，也就是 Safari 背后的引擎。

它最典型的使用方有。

Safari / WebKit
Apple 平台上的 WebKit 相关应用
Bun
JavaScriptCore framework
React Native 的可选回退引擎

JavaScriptCore 的影响力很大，但很多人未必意识到它已经悄悄进入了 Bun 这条新路线。

Bun 选择 JSC，而不是 V8，本质上是在赌启动速度和嵌入体验。

再看轻量和嵌入式这一支

这组引擎的共同点很直接，不是为了“统治浏览器”，而是为了“可以被塞进别的产品里”。

QuickJS

QuickJS 是 Fabrice Bellard 做的一个小而强的可嵌入引擎。

它的典型定位很明确。

小体积
低启动开销
易嵌入
可把 JavaScript 编译成独立可执行文件

QuickJS 的常见用途通常不是某个超级大 runtime，而是工具、脚本宿主、嵌入式程序、自定义产品里的脚本层。

如果你要做一个“自己的脚本系统”，QuickJS 这种引擎就很顺手。很多时候你不需要一个大而全的东西，只需要一个够轻、够稳、够好嵌的内核。

JerryScript

JerryScript 是面向 IoT 和微控制器的 JavaScript 引擎。

它的官方定位就是非常受限的设备，比如内存只有几十 KB 的场景。

所以它的典型使用方不是浏览器，也不是云平台，而是嵌入式设备、传感器、微控制器一类产品。

XS

XS 是 Moddable 的 JavaScript 引擎。

它主要服务于。

Moddable SDK
微控制器和嵌入式设备

XS 的思路跟 QuickJS、JerryScript 很像，都是把 JavaScript 带到资源受限设备上，只是它更强调标准兼容和嵌入式开发体验。

MuJS

MuJS 是一个轻量级、可嵌入的 JavaScript 解释器，官方文档里直接强调它适合嵌入到其他软件里作为脚本能力。

它常见于。

自定义宿主程序
文档处理、图形处理这类需要脚本扩展的产品

MuJS 的存在感没那么强，但它很适合说明一件事，JavaScript 不只属于浏览器和 Node，它也可以是一个很小的可嵌入脚本层。

移动端这边，Hermes 是最典型的

这一组最典型的是 Hermes。

Hermes

Hermes 是 Meta 做的 JS 引擎，主要为 React Native 优化。

它的使用方非常明确。

React Native

React Native 文档已经直接写明，Hermes 是默认引擎，并且在新版本里会带来更好的启动时间、内存占用和包体积表现。文档也保留了切回 JavaScriptCore 的配置路径，所以这里更准确的说法是：Hermes 是默认选择，JSC 是可选回退。

这个例子很重要，因为它说明了一件事，很多引擎不是为了“通用胜出”，而是为了某个具体产品形态做到极致。

Hermes 不是和 V8 正面硬刚浏览器份额，而是在移动端应用里，把启动速度和包体积压到更实用的区间。

Java 生态里，GraalJS 也占了一块

GraalJS

GraalJS 是运行在 GraalVM 上的 JavaScript 实现。

它最典型的落点有两个。

GraalVM
Java 应用里的脚本嵌入

GraalJS 的价值不是“又一个浏览器引擎”，而是它把 JavaScript 变成了 JVM 生态里的可嵌入语言。这个定位很清楚，也很实用。

如果一个团队本来就重度依赖 Java，想在系统里嵌脚本、做规则引擎、做扩展能力，GraalJS 就会很有吸引力。

ChakraCore

ChakraCore 是微软开源的 JS 引擎。

它今天更偏历史和存量用途，官方仓库也明确提到 Edge 已经不再使用 Chakra。

所以它的典型语境更多是：

旧项目
C API 嵌入
维护历史兼容

如果你今天在新项目里选引擎，大概率不会优先考虑它，但它依然是这张技术地图里绕不开的一块。

一张对照表

如果把这些引擎和常见 runtime / 产品直接对照，基本可以这样理解。

引擎	主要被哪些 runtime / 产品在用
V8	Node.js、Deno、Cloudflare Workers、Chromium 系浏览器
SpiderMonkey	Firefox、Servo、MongoDB server-side JavaScript（已废弃路径）、CouchDB 默认 query server（同时已有 QuickJS 选项）
JavaScriptCore	Safari / WebKit、Apple 平台应用、Bun、React Native 的可选回退
Hermes	React Native
QuickJS	各种嵌入式工具、脚本宿主、自定义应用
JerryScript	IoT、微控制器、极低资源设备
XS	Moddable SDK、嵌入式设备
MuJS	自定义宿主程序、轻量级脚本扩展
GraalJS	GraalVM、Java 应用、JVM 生态脚本嵌入
ChakraCore	存量项目、旧式嵌入场景

这张图真正说明了什么

这张表看起来像名单，但背后其实是三层非常清楚的分工。

1. 浏览器引擎会自然外溢到 runtime

V8 和 JavaScriptCore 都不是只待在浏览器里。

V8 直接外溢到了 Node、Deno、Cloudflare Workers。 JavaScriptCore 则外溢到了 Bun 和一些嵌入式应用场景。

这说明引擎的竞争，不只是浏览器内部的事，而是会直接影响整个开发者生态。你在上层选什么产品，往往就是在下层选什么引擎。

2. 轻量引擎靠嵌入场景活着

QuickJS、JerryScript、XS、MuJS 这种引擎，靠的不是巨大生态，而是“好嵌入、够轻、可控”。

如果你的产品本身就是一个宿主，那么引擎就不是主角，而是你给产品补的一层脚本能力。

3. 特定产品会反过来定义引擎

Hermes 就是最好的例子。

React Native 需要更好的启动、更低的内存、更小的包体积，于是 Hermes 这类引擎就会被产品需求反向塑形。

换句话说，有些引擎不是先找市场，再找产品，而是先被一个明确产品形态逼出来的。

开发者该怎么理解这件事

如果你只是日常写前端、Node、Bun、Deno，最常接触的其实只有三层。

V8 生态，Node、Deno、Workers 很多都在这上面
JavaScriptCore 生态，Bun 是典型代表
Hermes 生态，React Native 是典型代表

如果你在做嵌入式、IoT、桌面工具、自定义脚本宿主，那你会更常碰到 QuickJS、JerryScript、XS、MuJS 这种轻量引擎。

如果你在 Java 生态里做扩展脚本，GraalJS 就会更顺手。

所以“哪种引擎最好”这个问题，其实没那么有意义。

更有意义的是：

你的宿主是谁
你要什么样的启动、内存和兼容性
你到底是在做 runtime，还是在做一个需要嵌入脚本能力的产品

最后

JS 引擎不是一个“只有前端才关心”的话题。

它已经变成了 runtime、产品形态和基础设施选择的一部分。

你选 V8，往往意味着你更接近通用生态和成熟兼容。你选 JavaScriptCore，往往意味着你看重启动速度、嵌入体验，或者你本来就处在 Apple/WebKit 生态里。你选 Hermes，往往意味着你在移动端和包体积上有明确约束。你选 QuickJS、JerryScript、XS、MuJS，往往意味着你在做嵌入式或自定义宿主。你选 GraalJS，往往意味着你在 Java 世界里找脚本能力。

真正重要的不是“JS 有多少引擎”，而是你要把 JS 放进什么系统里，解决什么问题。