在 JavaScript 生态系统中，中间表示（IR）的碎片化一直是制约工具链互操作性的核心难题。不同前端工具（如 Babel、Esbuild、SWC、TypeScript 编译器）各自维护私有 IR，导致代码分析、反混淆和重构工具难以跨工具链复用。LLVM 社区提出的 JSIR（JavaScript Intermediate Representation）试图填补这一空白，其设计目标是构建一个公开、稳定且能够高保真往返于 JavaScript 源代码的高层 IR。本文将深入解析 JSIR 的设计动因、SSA 构造策略以及在编译器工具链中的集成路径。

设计动因：从碎片化到统一 IR

JavaScript 工具链的现状是典型的「巴别塔」问题。Babel 使用自己的 AST 格式，Esbuild 采用自定义 IR，SWC 则基于 Rust 实现的另一种 AST 结构。这种碎片化导致几个工程痛点：第一，跨工具链的代码转换（如从 TypeScript 到 React Native 代码）需要编写多个适配层；第二，安全分析工具（如反混淆、污点追踪）难以在不同工具之间复用分析结果；第三，升级某一工具的内部版本可能破坏依赖其 IR 的下游工具。

JSIR 的核心设计动因正是解决上述互操作性问题。根据 LLVM 官方讨论帖，JSIR 被定位为「公开、稳定的 JavaScript 高层 IR」，其设计遵循三个关键原则。首先是 publicly documented and stable，即 IR 规范必须公开文档化并保持长期稳定，类似于 LLVM IR 的设计理念；其次是 source fidelity，即 IR 必须保留几乎所有源代码级别的信息，支持从 IR 往返到 JavaScript 源代码的高保真转换；最后是 high-level semantics，即 JSIR 面向高层分析和转换（如代码分析、反混淆、重构），而非面向低层代码优化。

这种定位使得 JSIR 与现有的 JavaScript 编译器形成了互补关系。JSIR 并非要替代 Esbuild 或 SWC 的内部 IR，而是作为上层统一的分析表示层，下层可以对接各种编译器后端进行代码生成。这种分层架构与 MLIR 的「tower of IRs」理念一脉相承，允许不同抽象层次的 IR 之间进行渐进式 lowering。

SSA 构造策略：面向数据流分析的设计

JSIR 在 SSA（静态单赋值形式）的使用上采取了与经典 LLVM IR 不同的策略。传统 LLVM IR 要求函数内所有值严格遵循 SSA 形式，即每个值只能被赋值一次，这种设计使得数据流分析变得 trivial。但 JSIR 作为高层 IR，需要在保留 JavaScript 语义的同时支持灵活的代码变换，因此其 SSA 构造策略更加务实。

JSIR 的 SSA 设计核心是 明确的使用 - 定义链（use-def chains）。在 JSIR 中，每个值（value）一旦被定义就不可再修改，这与 SSA 的核心精神一致。但 JSIR 允许在特定场景下保留可变的局部状态，用于建模 JavaScript 的变量提升（hoisting）和临时变量。例如，函数作用域内的 var 声明在 JSIR 中被显式建模为函数级别的 SSA 值，而非块级的单次赋值形式。

控制流表示是 JSIR 区别于传统 LLVM IR 的另一个关键点。JSIR 使用 MLIR 的区域（region）来建模 JavaScript 的结构化控制流。具体而言，每个 if 语句、循环语句、try-catch 块都对应一个独立的 MLIR 区域，区域内嵌套的代码块（block）保持了原有的控制流结构。这种设计的优势在于：它直接映射了源代码的控制流结构，使得从源代码到 IR 的转换以及从 IR 到源代码的反向转换都变得高度可靠。

在数据流语义方面，JSIR 特别关注 JavaScript 的短路求值（short-circuit evaluation）特性。对于 a && b 和 a || b 这类表达式，JSIR 使用显式的条件分支操作来建模，确保后续的污点追踪（taint tracking）和类型推断能够准确捕获数据流向。这种设计使得安全分析工具能够在 JSIR 层面检测诸如跨站脚本（XSS）漏洞等安全问题，而无需解析原始源代码的语法细节。

JavaScript 编译器工具链集成路径

将 JSIR 集成到现有 JavaScript 工具链中需要考虑几个关键工程路径。首先是 ESTree 兼容层的设计。ESTree 是 JavaScript AST 的事实标准，Babel、Esbuild 等工具都围绕 ESTree 构建。JSIR 通过提供 ESTree 到 JSIR 的转换层，允许现有工具链无缝接入。转换层的设计目标是保持一一对应的语义映射，同时利用 JSIR 的区域结构补充 ESTree 中缺失的控制流信息。

其次是 多层 lowering 架构。JSIR 作为高层 IR，可以 lowered 到多种目标：对于需要生成高效机器码的场景，可以 lowering 到 LLVM IR 进行优化和代码生成；对于 WebAssembly 编译目标，可以 lowering 到 MLIR 的相关 dialect（如 SPIRV-Lowering）；对于需要生成可读 JavaScript 输出的场景（如代码格式化工具），可以直接从 JSIR 逆向生成源代码。

在实际部署方面，Google 已在生产环境中将 JSIR 用于代码分析和反混淆工作。根据 2024 年 LLVM 开发者会议的演示，JSIR 被用于大规模 JavaScript 代码库的恶意代码检测和自动化反混淆流程。其优势在于：统一的 IR 使得不同分析工具可以共享分析结果，避免重复解析和转换开销；同时，JSIR 的高层语义使得安全分析规则更易于编写和验证。

对于希望采用 JSIR 的团队，以下工程参数可作为参考：转换层延迟目标应控制在单文件 100 毫秒以内（以 1MB JavaScript 文件为基准）；JSIR 到 LLVM IR 的 lowering 过程应保持语义等价性验证；反混淆工具链中，JSIR 层面的代码变换应保留原始源代码的位置映射信息，以便生成可读的转换后代码。

小结

JSIR 的出现为 JavaScript 工具链提供了一种新的互操作基础设施。其核心价值在于通过公开、稳定的 IR 规范，使得代码分析、反混淆、重构等工具能够跨工具链复用。通过在高层 IR 中合理运用 SSA 形式和 MLIR 区域结构，JSIR 在保持 JavaScript 语义的同时，为编译器工具链的模块化设计提供了坚实基础。

参考资料

  • LLVM Discourse: [RFC] JSIR: A High-Level IR for JavaScript
  • 2024 LLVM Developers' Meeting: JSIR - Adversarial JavaScript Detection With MLIR