Jun 27, 2025

JavaScript 预编译（AOT）：现状与未来 —— Oliver Medhurst 演讲整理

。在现代 Web 和服务端开发中，JavaScript 引擎的演进一直是性能提升和开发体验优化的关键领域。近日，TC39 特邀专家Oliver Medhurst 在一次技术分享中详细介绍了 JavaScript 的 ahead-of-time 编译（AOT）技术，结合自身开源项目的实践，带来了许多值得业界关注的新思考。本文将根据其演讲内容与对话进行梳理，带你深度了解这一前沿话题。

1. JavaScript 引擎简介与现状

众所周知，目前主流的 JavaScript 引擎包括 V8（Chrome、Node.js、Deno）、JavaScriptCore（Safari）以及新兴的 Bun 等。十多年前，大多数引擎只是解释执行（interpreter），优点是简单，但速度较慢。

V8 在 Chrome 中率先提出了 JIT（Just-in-time，即时编译），即先将 JavaScript 编译为机器码再执行，虽然复杂度更高，但大幅提升了性能。现代 JS 引擎一般包含解释器和多阶段 JIT，不同阶段平衡编译耗时与执行效率。

JIT 带来了极高的性能（理论峰值可快十倍），但实际应用下也有显著缺点：

安全性问题突出：约一半的引擎安全漏洞来自 JIT。最突出的安全问题是利用 JIT 相关优化过程出现漏洞——攻击者可以通过精心构造的代码模式，误导 JIT 编译器优化出有缺陷的机器码，从而突破原本的安全边界。以 2018 年发现的 Apple Safari JavaScriptCore JIT 漏洞（CVE-2018-4233）为例，这是一个广受关注的 JIT 漏洞。攻击者通过特定方式诱使 JIT 编译器生成有问题的代码，可造成内存越界读写甚至执行任意代码。该漏洞尤其危险，因为它可以用于远程攻击，无需用户任何交互，仅凭访问一个恶意网页即可完成攻击。这一漏洞的出现，使得主流浏览器纷纷加大了对 JIT 优化下安全性的关注和防护。
资源开销大：内存和启动时间略高，对于嵌入式等资源受限场景不是最优解。
1. 额外的内存需求：
- 传统 Interpreter 直接对字节码逐条解释执行，代码和数据结构较精简；
- JIT 需要将部分 JavaScript 代码动态编译为机器码，“代码缓存”以及编译过程中用到的中间数据结构（如抽象语法树、优化信息、监控和分析数据等）会占用大量内存；
- 多阶段的 JIT（包括 baseline JIT、优化 JIT）之间不断产生和替换不同版本的机器码，进一步抬高内存成本。
1. 更长的启动和“预热”时间：JIT 通常需要先收集运行时的统计信息（如类型信息、热点分析），等到代码“热”起来时再进行编译和优化。这个“分析—编译—热代码重编译”的循环本身就是一笔很大的时间和计算负担。
2. 安全措施的资源开销：由于 JIT 容易带来安全风险，许多现代浏览器和引擎会增加沙箱、执行快照、JIT 隔离区等安全策略，这些机制本身又增加了内存和计算资源的消耗。
3. 嵌入式和资源受限设备的不适应：在嵌入式等存储、内存极为有限的设备上，JIT 的“大胃口”令其难以部署，同时“冷启动”性能远不如解释器，影响体验。

2. AOT 编译：想象变为现实

在传统的 C++、Rust 开发中，“ahead-of-time”编译是理所当然的，即源码直接编译成二进制程序。那么，JavaScript 能否走同样路线？

Oliver 的回答是肯定的！他自 2023 年专注开发了一款支持 JavaScript AOT 编译的新项目。通过实际演示，他展示了用多种常见工具（Node.js、Deno、Bun）运行同一简单的 JS 脚本。在将脚本编译为原生二进制时，不同方案的二进制体积差异显著：

Node.js/Deno 编译后的可执行文件体积可达百兆
Bun 相对精简
Oliver 的 AOT 工具 编译后仅有 20KB，且运行速度极快，内存占用低至 1MB

对于 WebAssembly 的支持也是亮点：

主流方案（javy 等）生成的 WASM 文件约 1MB
Oliver 工具生成的 WASM 只需 4KB，网络传输和加载速度优势巨大

3. 技术原理与架构简述

AOT 的基本流程为：

解析 JavaScript 源码，生成抽象语法树（AST）
可选路径：直接生成 WebAssembly，或进一步生成 C 代码，由 Clang 编译为原生二进制

该方案设计简洁，目标聚焦服务端或非浏览器场景，不追求极致即时性，而是高度优化后的单次执行体验。代码实现全部用 JavaScript/TypeScript 编写，项目规模控制在 2 万行左右，便于社区参与与理解。

4. 功能支持与限制

实践中，AOT 编译器已支持 TypeScript，能根据类型信息进行定向优化，比如将某变量声明为 i32，编译器会直接优化相关代码逻辑，带来显著加速。

但并非一切功能都能完美实现，以下为当前的主要难点：

动态性/元编程相关：如 eval、with、new Function 等动态代码难以在 AOT 阶段处理，目前仅支持简单静态场景。
代理对象（Proxy）与高级语言特性：理论上可行，但优先级较低，暂未完全实现。
ES 各标准特性兼容度：目前通过了 59% 的 Test262 规范测试，重点在常用内置方法，对正则、国际化等部分功能还在逐步完善。
内存管理/Garbage Collection：目前实现较简单，对于短时任务（如云函数 Lambda 场景）问题不大，长远来看需完善内存分配与回收机制，未来有计划支持 WebAssembly GC 并允许运行时切换不同 GC 模式。

结语

Oliver 项目的开源属性吸引了越来越多的贡献者。许多实用性、规范兼容相关的 bug 修复均由社区合作完成。对于未来规划，Oliver 表示，将持续攻坚更难的 ECMAScript 特性兼容和性能优化，同时考虑增加对多种 GC 的灵活支持，使其在嵌入式、云原生、WebAssembly 场景下具备极强竞争力。

他也坦言，缩小二进制体积虽对大部分开发者影响有限，但对嵌入式设备、带宽敏感型应用极为重要，能大大降低“隐性成本”。

JavaScript 从 “解释执行” 到 “即时编译”，再到今天迈向 “静态编译/AOT”，技术的每一步都在拓展它的边界。Oliver 的工作为 JavaScript 的工程化、分发与性能优化开辟了新思路，也让更多开发者看到了 JS 工程体系的丰富可能性。期待未来开放且多元的 JavaScript 生态能在更多领域释放潜能！

JavaScript 预编译（AOT）：现状与未来 —— Oliver Medhurst 演讲整理