我不知道的 V8（11）— 惰性解析：V8 如何用"按需编译"提升启动速度

加载一个大型 JavaScript 文件时，V8 并不会立即把里面所有函数都完整解析和编译。如果这样做，首次执行 <script> 的时间会随着代码量线性增长。V8 的实际策略是惰性解析（Lazy Parsing）——先快速扫描，推迟函数体的完整解析，等到函数真正被调用时再处理。这套机制和闭包的实现紧密相连。

一、为什么需要惰性解析

考虑一个典型的 web 应用：

// 10000 行的 bundle.js
function initMap() { ... }        // 页面加载时不一定用到
function renderChart() { ... }    // 点击某按钮才用到
function processPayment() { ... } // 用户结账才用到
// ... 大量只在特定场景下才调用的函数

// 只有这个会在页面加载时立即执行
initApp();

如果加载时完整解析每一个函数，就要为 initMap、renderChart、processPayment 生成 AST 节点、符号表、作用域信息……这些工作绝大多数在当前时刻是浪费的。

V8 的解法：先用**预解析器（PreParser）**快速扫描，只做必要的工作，把完整解析推迟到函数被调用时。

二、PreParser：轻量扫描器

PreParser 是 V8 内置的轻量级解析器，职责是在不完整解析的前提下，快速提取关键信息：

语法有效性检查：确认括号匹配、关键字合法，发现语法错误
函数声明识别：记录函数的名称、位置（源码 offset）、参数数量
作用域层级标记：记录哪些变量可能被内层函数引用（闭包候选）

PreParser 不生成完整 AST，不创建详细符号表，执行速度比完整解析器快约 2-3 倍。

function outer() {
  const x = 1;

  function inner() {
    // PreParser 识别：这是一个函数声明
    return x; // PreParser 标记：x 被引用，outer 的 x 是闭包变量
  }

  return inner;
}
// PreParser 扫描完成后：
// - 知道 outer 和 inner 的存在
// - 知道 inner 引用了 outer 的 x（需要创建闭包上下文）
// - 但 inner 的函数体字节码还没有生成

三、惰性解析的触发与展开

当 outer() 被调用时，V8 触发完整解析：

调用 outer()
  → outer 函数体完整解析（生成完整 AST）
  → 执行 outer 的函数体
  → 遇到 inner 的定义
    → inner 再次进入惰性状态（只记录位置，不生成字节码）
  → 返回 inner 函数对象

调用 inner()（即 fn()）
  → inner 函数体完整解析
  → Ignition 生成字节码
  → 执行字节码

这是一个递归的惰性策略：outer 的展开不会立即触发 inner 的展开，直到 inner 真正被调用。

V8 用 ParseInfo 结构记录每个未解析函数的状态（源码位置、PreParser 收集的作用域信息），等到需要时快速恢复并完成解析。

四、闭包与惰性解析的协作

闭包的正确工作依赖 PreParser 的作用域分析。

当 PreParser 扫描到 inner 引用了 outer 的 x 时，它会在 outer 的作用域信息中标记：x 需要被”上下文分配（Context Allocation）“，而不是”栈分配”。

这个区别很重要：

栈分配：变量存在 outer 的调用栈帧上。outer 执行完毕，栈帧销毁，变量消失
上下文分配：变量存在 V8 创建的 Context 对象（堆上）里。即使 outer 的栈帧销毁，Context 对象还在，inner 的闭包引用它

function makeCounter() {
  let count = 0; // PreParser 检测到被 increment 引用 → 标记为上下文分配

  function increment() {
    count++; // 引用 outer 的 count
    return count;
  }

  return increment;
}

const counter = makeCounter(); // makeCounter 执行完毕，栈帧销毁
counter(); // 1  ← count 仍然可访问，因为存在 Context 对象上（堆）
counter(); // 2

如果 PreParser 没有提前分析出 count 被 increment 引用，V8 就可能把 count 栈分配，makeCounter 返回后 count 就消失了，counter() 调用时会找不到 count。

五、一个容易被误解的场景：立即执行函数

惰性解析对立即执行函数（IIFE）有特殊处理：

// 普通函数：惰性解析
function init() {
  // 预解析：跳过函数体
}

// IIFE：V8 识别出它会立即执行，跳过预解析直接完整解析
(function () {
  // 直接完整解析，不走惰性路径
})();

V8 有启发式规则：如果函数定义后紧跟 ( 或其他调用符号，会猜测它是 IIFE，跳过预解析直接进入完整解析，避免”预解析 → 发现立即调用 → 再完整解析”的双重开销。

六、对开发实践的影响

影响一：大文件优化

惰性解析是 V8 应对大型 bundle 的内置机制。但这不意味着可以随意增大 bundle 体积——预解析本身也有开销，文件越大，PreParser 扫描的时间越长。代码分割（Code Splitting）让 V8 可以更晚加载更少的代码，与惰性解析互补。

影响二：闭包的内存考量

PreParser 的作用域分析可能把更多变量标记为”需要上下文分配”（保守策略，宁可多分配也不漏分配）。这意味着一些实际上不需要闭包引用的变量，也可能被分配到堆上，增加内存占用。

// 这里的 bigData 被 inner 引用，会上下文分配
function outer() {
  const bigData = new Array(1000000); // 大数组
  function inner() {
    return bigData.length; // 只用了 length，但 bigData 整个被保留
  }
  return inner;
}

// 如果 inner 不需要 bigData，避免闭包引用
function outer() {
  const bigData = new Array(1000000);
  const len = bigData.length; // 只保留需要的值
  function inner() {
    return len; // 引用 len，bigData 不被上下文分配，可以被 GC
  }
  return inner;
}

影响三：避免不必要的深层嵌套

每层嵌套函数都增加了 PreParser 需要分析的作用域层级，以及运行时的作用域链长度。在热点代码中，过深的嵌套既增加了启动分析的开销，也增加了变量查找时遍历的层级数。

七、总结

V8 的惰性解析让大型 JavaScript 应用的首次执行时间不随代码量线性增长：PreParser 快速扫描，推迟不必要的完整解析；函数被调用时再展开，生成字节码执行。

闭包的正确工作依赖 PreParser 的作用域分析。正是因为 PreParser 在扫描阶段就识别了哪些变量会被跨作用域引用，V8 才能在运行时正确地把这些变量分配到堆上的 Context 对象，而不是生命周期更短的调用栈帧。

本系列其他文章：