JavaScript闭包底层原理：从执行上下文与作用域链解析

在 JavaScript 中，闭包常被描述为“能够访问其他函数作用域变量的内部函数”。从底层引擎视角来看，闭包的本质是函数在定义时静态绑定了其外层词法环境（Lexical Environment），即使该外层函数的执行上下文（Execution Context）已经从调用栈弹出销毁，其对应的环境记录（Environment Record）由于仍被内部函数的内部属性所引用，依然被保留在堆内存中不被垃圾回收机制释放。本文将从执行上下文的生命周期、作用域链的静态绑定规则以及堆栈内存分配机制三个维度，完整还原闭包在 V8 等引擎中的底层运作过程。

一、执行上下文与调用栈的物理模型

JavaScript 引擎执行脚本时，代码的运行状态由执行上下文（Execution Context，简称 EC）进行管理。每当一段可执行代码（全局代码、函数体、eval）被调用，引擎就会为之创建对应的执行上下文并压入调用栈（Call Stack）。

调用栈是一个遵循“后进先出”（LIFO）的数据结构。栈顶始终是当前正在执行的代码上下文。当函数执行完毕返回时，该上下文便会从栈顶弹出。然而，传统的栈帧弹出往往意味着局部变量的完全释放，而 JavaScript 之所以能够产生闭包，核心就在于执行上下文栈与词法环境堆内存的分离设计。

在许多系统级语言（如 C/Rust）中，局部变量随栈指针的回退而被自动覆盖。但在 JavaScript 中，执行上下文只是轻量级的调度载体；一旦变量被内部嵌套函数引用，变量所处的环境记录会被分配或逃逸至堆内存中。上下文出栈后，堆中的数据依然存在独立的引用链路。

二、词法环境与作用域链的静态绑定机制

ECMAScript 规范中，执行上下文中与变量解析直接相关的核心组件是词法环境（Lexical Environment）。每个词法环境由两部分组成：

1. 环境记录（Environment Record）：具体存储当前作用域内绑定的变量、函数声明和参数列表（在 ES6 中细分为声明式环境记录与对象式环境记录）。
2. 外部环境引用（outer Reference）：指向当前作用域在逻辑外层的另一个词法环境引用，根节点指向全局环境（其 outer 为 null）。

所谓的作用域链（Scope Chain），在物理结构上并不是一个线性的数组，而是一个由 outer 引用串联而成的单向链表。

理解闭包最关键的一点在于：函数的作用域链是在函数被“声明（定义）”时确定的，而不是在函数被“调用”时决定的。在函数对象创建的那一刻，JavaScript 引擎会将其所在的当前词法环境记录赋值给该函数的内置插槽 [[Environment]]（在早期 ES3 规范中称为 [[Scope]]）。

三、闭包生命周期底层推演：出栈前后的内存对比

我们通过一段经典的计数器工厂代码，具体分析 V8 等现代引擎在执行过程中的栈堆状态演变：

function createCounter(initialValue) {
  let count = initialValue;
  function counter() {
    count += 1;
    return count;
  }
  return counter;
}

const myCounter = createCounter(10);
myCounter(); // 输出 11
myCounter(); // 输出 12

在这段代码执行时，经历了两个关键阶段的状态变化：

阶段一：createCounter(10) 调用与执行

引擎创建 createCounter 的执行上下文并入栈。在此期间，局部变量 initialValue: 10 和 count: 10 被分配。紧接着声明内部函数 counter。引擎通过静态语法分析（Escape Analysis 逃逸分析）发现 counter 内部引用了外部的 count 变量。

此时，V8 不会将 count 分配在常规的调用栈帧中，而是将其分配在一个名为 Context（上下文对象） 的堆结构中。同时，counter 函数的 [[Environment]] 指针保存了这个 Context 对象的地址。

阶段二：createCounter 执行完毕并返回

createCounter 函数返回内部函数对象 counter，并赋值给全局变量 myCounter。此时，createCounter 的执行上下文生命周期结束，从调用栈中弹出。

在通常情况下，出栈意味着释放所有变量。但此时，由于全局变量 myCounter 引用着堆中的函数对象，而该函数对象的 [[Environment]] 属性依然引用着 createCounter 的词法环境记录。从垃圾回收（GC）根节点（Root）进行可达性遍历时：

Global Context → myCounter → Function Object → [[Environment]] → Closure Context { count }

这条强引用链完全成立，因此垃圾回收器绝不会回收这块内存，闭包由此形成并持久驻留。

四、块级作用域与循环闭包的底层差异

在 ES6 引入 let 与 const 之前，var 在循环中经常导致经典的闭包失效问题。通过执行上下文与环境记录的创建时机，可以彻底澄清这一现象：

// 案例 1: var 声明（共享同一个词法环境）
for (var i = 0; i < 3; i++) {
  setTimeout(() => console.log(i), 100);
}
// 最终输出: 3, 3, 3

// 案例 2: let 声明（每次迭代生成独立词法环境）
for (let j = 0; j < 3; j++) {
  setTimeout(() => console.log(j), 100);
}
// 最终输出: 0, 1, 2

从底层原理解释这两者的分歧：

• var 的处理机制：var 没有块级作用域概念，其变量直接登记在当前外层函数或全局执行上下文的变量环境记录（VariableEnvironment）中。3 个 setTimeout 的回调函数内部 [[Environment]] 均指向同一个全局环境记录。当异步计时结束回调触发时，循环已完成，查找到的 i 自然全是 3。
• let 的处理机制：ECMAScript 规范规定，在带有 let 的 for 循环体中，每一次迭代循环都会显式创建一个新的词法环境块（Lexical Environment Block），并将前一次迭代结束时的值复制进新块的记录中。因此，每次生成的箭头函数在创建时，其 [[Environment]] 分别精确绑定了当前迭代对应的独立环境记录（分别存有 0, 1, 2）。

五、闭包的内存治理与底层机制全景总结

由于闭包会阻止垃圾回收器回收外层环境的变量，如果不加节制地在全局持久引用或高频挂载闭包，可能会导致非预期内存驻留（常被称为内存泄漏）。