JavaScript ES6+ 块级作用域与闭包底层机制解析

作者：青柠

时间：2026-10-30

深入解析 ECMAScript 规范中块级作用域与闭包的底层运行机制，涵盖执行上下文、词法环境与变量环境分层、暂时性死区成因、堆内存闭包逃逸及 for 循环每轮迭代独立环境的具体实现。

文章目录

在现代 JavaScript 引擎实现中，块级作用域并非通过创建完整独立的栈帧开销来完成，而是复用同一个执行上下文，通过动态压入和弹出嵌套的“词法环境（Lexical Environment）”实现隔离；而闭包则是内部函数的内部私有槽 [[Scopes]] 对这套词法环境链条的长久持有，迫使相关变量逃逸至堆内存中得以常驻。

一、执行上下文模型：词法环境与变量环境的双层架构

在 ES5 时代，JavaScript 仅存在全局作用域与函数作用域，变量均使用 var 声明。由于缺乏块级限制，声明提升（Hoisting）常常导致意料之外的变量覆盖。为了在保持向后兼容的同时正式引入 let 与 const 的块级作用域能力，ECMAScript 规范对执行上下文（Execution Context）的内部结构进行了重要重构。

在现代规范中，当一个执行上下文被激活时，它主要维护两套独立的环境指针：

VariableEnvironment（变量环境）：专门用于登记由 var 关键字声明的变量以及顶层函数声明。该环境记录项在编译阶段就确定了所有标识符，并将它们初始化为 undefined（函数声明则直接绑定函数体），这也是经典声明提升的根源。
LexicalEnvironment（词法环境）：负责管理由 let、const 以及代码块内部声明的标识符。它能够根据代码块 { ... } 的嵌套执行过程发生动态链式改变。
Outer Reference（外部环境引用）：记录当前环境在词法层面的直接上级环境，所有跨层级的标识符解析（作用域链查找）均沿着该指针逐级向上遍历，直到全局环境。

JavaScript ES6+ 块级作用域与闭包底层机制解析 — 图 1：执行上下文结构与词法环境/变量环境分层架构

二、块级作用域底层运作：词法环境的动态压入与暂时性死区

当 JavaScript 引擎在执行函数或全局代码遇到一个花括号包裹的块 { ... } 时，如果块内包含 let、const、class 或块级函数声明，执行上下文并不会创建新的执行栈帧（Call Stack Frame），而是就地执行以下五个确定性步骤：

暂时性死区（TDZ）的规范定义

很多人认为 let 和 const 没有变量提升，这并不准确。规范中变量的生命周期被明确拆分为三个独立阶段：

创建（Declaration / Creation）：在进入作用域时，引擎已知晓该标识符的存在，并在环境记录项中注册该名字。var、let、const 均在此阶段完成提升。
初始化（Initialization）：为变量分配内存并赋初值。var 声明在创建的同时立即被初始化为 undefined；而 let 和 const 则保持在未初始化（uninitialized）状态。从环境创建到初始化代码执行之前的这段时间窗口，就被称为暂时性死区（Temporal Dead Zone）。
赋值（Assignment）：当代码执行到明确的赋值语句时，将右侧表达式计算得到的值存入变量内存中。

引擎底层行为：如果在初始化阶段之前读取或写入该标识符，JavaScript 引擎会触发内在的断言检查，立即抛出 ReferenceError: Cannot access 'x' before initialization，以此杜绝未准备妥当状态下的数据误读。

三、闭包底层机制：作用域链与堆内存逃逸

闭包（Closure）是函数与其词法环境的组合。从现代引擎的角度看，闭包绝不是一个虚拟的概念，而是有明确数据结构支撑的物理实体。

当一个函数被创建时，引擎会为该函数对象注入一个内部私有插槽 [[Scopes]]（ECMAScript 规范中称为 [[Environment]]）。该插槽直接存储了当前创建函数时所在的外部词法环境引用：

function createCounter() {
  let count = 0; // 位于 createCounter 的词法环境记录项中
  return function increment() {
    count += 1;
    return count;
  };
}

const counter = createCounter();
counter(); // 1
counter(); // 2

当 createCounter() 执行完毕时，按照正常的调用栈行为，其执行上下文应该从调用栈顶部弹出（Pop）并被销毁。但为什么后续调用 counter() 依然能够正确读取并修改 count？

其关键就在于逃逸分析与堆内存常驻机制：

调用栈销毁的仅仅是执行上下文栈帧（Execution Context Frame），包含当前正在运行的 PC 指针与临时计算寄存器。
而该上下文所对应的环境记录项（Environment Record）由于被内部函数 increment 的 [[Scopes]] 强引用，引擎并不会将其在栈上直接丢弃，而是将其保留在堆内存（Heap）中。
在垃圾回收（GC）执行可达性标记时，全局对象持有 counter 变量，counter 函数对象通过 [[Scopes]] 持有该闭包环境，从而构成了完整的可达引用链。

四、经典对照：for 循环中 var 与 let 的引擎实现差异

在日常开发中，前端开发者经常面对经典面试题：为什么在 for (var i = 0; ...) 循环中添加定时器回调输出的总是终值，而改为 for (let i = 0; ...) 之后即可按预期输出每轮索引？

从 ECMAScript 规范定义及 V8 实现层面剖析，这两者有本质的区别：

var 循环：var i 被直接注册在所属函数（或全局）的 VariableEnvironment 中。整场循环只存在一个共享的 i 变量存储单元。每次循环迭代仅仅是在同一个内存位置重写数值，定时器异步回调执行时只能读取到循环终止时的最终值。
let 循环：ECMAScript 规范在 ForDeclaration 评估算法中做出了明确规定——在每次迭代求值（Per-iteration Evaluation）时，引擎都会为当前循环体创建一个全新的词法环境（Lexical Environment）。
上一轮迭代结束时 i 的更新结果，会被拷贝作为新一轮迭代环境中 i 的初始值。当异步闭包捕获 i 时，捕获的是属于当前那次具体迭代的独立词法环境实例，因此每个回调函数各持一份快照。

五、引擎性能优化：上下文分配剪枝与内存排查

如果每一个函数与块级作用域都机械地在堆上分配完整的词法环境记录，现代 JavaScript 引擎的内存占用与 GC 压力将难以承受。因此，如 Google V8 等工业级引擎实施了精细的作用域分析与剪枝优化（Context Allocation & Scope Analysis）：

栈上分配（Stack Allocation）：在 AST 解析阶段，引擎会检查当前块或函数内的所有局部变量。如果发现某个变量从未被任何内部嵌套函数引用（没有闭包逃逸），那么该变量将被直接分配在连续的机器栈上，随执行上下文弹出瞬间释放，完全零 GC 负担。
上下文提升（Context Object Promotion）：只有当变量被内部函数显式引用时，V8 才会为该作用域生成一个堆上分配的 Context 对象，仅将那些真正被捕获的变量放入其中。

闭包内存泄漏隐患与排查方法

尽管引擎具备剪枝能力，但同一个词法作用域内声明的多个闭包函数会共享同一个 Context 对象。这意味着：如果函数 A 引用了巨量数据对象 largeData，而同一个作用域下的函数 B 仅仅是一个挂载在全局事件监听器上的普通处理函数，即便函数 B 本身没有用到 largeData，由于共享了外部词法环境，largeData 也无法被垃圾回收。

排查此类问题时，可以在 Chrome DevTools 中按以下步骤定位：

打开控制台 Memory 面板，选择 Heap snapshot（堆快照）并点击获取基准快照。
触发相应业务操作后再次抓取快照，切换到 Comparison（对比）视图。
在构造函数过滤器中搜索 system / Context 或 Closure，即可直观查看哪些词法环境仍在被闭包的 [[Scopes]] 引用链强行维持存活。