关于JS处理中编译器与解释器的核心技术问题咨询

问题1：解释器处理的输入是什么，为什么JS引擎要同时使用编译器和解释器？ #

• 目前主流JS引擎的解释器处理的是编译器预处理生成的字节码，既不是人工编写的原始JS源码，也不是编译完成的机器码。
• 完整处理流程顺序为：编译器先将JS源码解析为抽象语法树（AST），再编译为字节码后交给解释器执行，不存在解释器直接把JS转成字节码的环节。
• 两者配合的核心原因是平衡启动速度和运行性能：解释器可以直接执行字节码，无需等待全量编译完成，大幅降低程序启动等待耗时；而JIT编译器会识别频繁执行的热点代码，将其编译为高度优化的机器码，运行效率远高于解释执行，二者刚好互补。

问题2：编译器能否直接将JS代码编译为机器码，完全不需要解释器参与？ #

• 技术上完全可以实现。比如Chrome 59之前的V8引擎就没有字节码和解释器环节，会直接将JS源码编译为机器码执行；此外将JS预编译为原生可执行程序的工具（如pkg）、JS转Wasm的编译方案，都可以实现仅靠编译器完成JS代码的执行，运行时无需解释器参与。
• 但纯编译方案存在明显缺陷：一是编译后的机器码体积远大于字节码，会占用更多存储和内存空间；二是JS是动态类型语言，提前编译无法获取运行时的类型信息，无法做针对性的性能优化，最终执行效率反而低于“解释+JIT编译”的混合模式，因此当前主流JS引擎都不会采用纯编译的执行方案。

问题3：所有浏览器/设备处理JS都需要同时用到编译器和解释器吗？是否存在仅用单种方式的场景？ #

• 并不是所有场景都需要同时使用二者，两种单模式的场景都存在：
  • 仅用解释器的场景：早期的JS引擎均为纯解释执行，比如IE9之前的JS引擎、初代Safari的JS引擎，都是直接解析JS源码后逐行解释执行，没有编译环节；现在很多面向IoT设备的轻量JS引擎（如JerryScript）受限于硬件性能，也会采用纯解释执行的模式，不需要编译模块。
  • 仅用编译器的场景：预编译为原生程序的JS应用，比如用pkg打包的Node.js工具，运行时直接执行提前编译好的机器码，不需要解释器参与；部分对性能要求极高的业务会提前将JS代码编译为Wasm，运行时直接执行Wasm对应的机器码，也不需要JS解释器工作。

内容的提问来源于stack exchange，提问作者Ian