JavaScript解析器分阶段执行代码，因引擎需先语法分析和编译，采用“预解析+懒编译”策略：函数声明预解析但主体懒编译，箭头函数赋值时仅语法检查，class定义时即全量编译，eval/new Function强制同步编译。
JavaScript 解析器为什么分阶段执行代码
因为 JavaScript 引擎（如 V8）必须先完成 Parse（语法分析）和 Compile（编译）才能执行，而这两个阶段天然可拆分为「预解析 + 懒编译」——不是所有函数都会立刻被编译成机器码，只有可能被执行的才进入后续阶段。
典型表现是：function foo() { while(true) {} } 这种死循环函数，只要没被调用，V8 就不会真正编译它内部的字节码；但若写成 const bar = () => { while(true) {} }，箭头函数表达式在初始化时就会触发完整编译（取决于上下文和引擎版本）。
哪些代码会触发提前编译？哪些会被懒编译？
关键看「是否形成可立即执行的函数对象」以及「是否出现在热路径上」：
-
function declaration（函数声明）：会被提升并预解析，但主体通常懒编译（除非被eval或new Function动态触发） -
function expression和arrow function：赋值时只做语法检查，真正编译推迟到首次调用 -
class：整个类体在定义时就被完全解析并编译（包括方法体），即使方法从未调用 -
eval()或new Function(...)：强制同步全量编译，开销大且无法被优化
示例对比：
立即学习“Java免费学习笔记（深入）”；
function warmUp() {
// ✅ 被预解析，但 body 不编译，直到第一次调用
}
const lazyFn = function() {
// ✅ 表达式本身不触发编译，首次 call 才编译
};
class HeavyClass {
method() {
// ❌ 即使 never called，method 也会在 class 定义时被编译
}
}
如何利用分阶段特性减少首屏 JS 开销？
核心思路是：把非首屏逻辑从「定义即编译」结构里移出，改用延迟可执行形态，让解析/编译压力后置。
- 避免在模块顶层写
class定义大量未使用的方法；改用工厂函数或仅导出构造逻辑 - 把工具函数从
export function util() {...}改为export const util = () => {...}，尤其当该函数只在少数交互中触发 - 对大型配置对象或 JSON 数据，不要直接写
const config = { a: fn1(), b: fn2() }，否则fn1/fn2会被立即求值+编译；改用 getter 或 lazy init 函数 - 慎用
import()动态导入虽解决加载问题，但它的回调函数体仍会在 resolve 后立刻编译——如果只是注册监听器，可考虑用字符串模板 +setTimeout延迟触发（极端场景）
容易被忽略的陷阱：try/catch 和 with 会破坏懒编译
V8 中，任何包含 try/catch 的函数，无论是否实际抛错，都会禁用某些优化，并大概率跳过懒编译路径，转为立即全量编译。这不是 bug，而是为了保证错误堆栈和变量捕获的语义正确性。
常见误操作：
// ❌ 这个函数哪怕从不执行，也会被立即编译
function risky() {
try {
doSomething();
} catch (e) {
handleError(e);
}
}
// ✅ 把 try/catch 内收，外层保持纯净
function safe() {
return doSomething(); // 无 try/catch，可懒编译
}
function safeWrapper() {
try {
return safe();
} catch (e) {
handleError(e);
}
}
同理，with 语句、arguments 显式引用、eval 在作用域内出现，都会让函数失去懒编译资格。
真正影响性能的，往往不是执行慢，而是「本不该此时编译的代码，被强行拉进首帧编译队列」——这个阶段没有 warning，也不报错，只默默拖慢 TTI。
