JavaScript闭包是什么：图解作用域链与形成机制

一、从最小示例透视闭包：它解决了什么现象

在许多传统编程语言中，函数的局部变量分配在栈上。当函数执行结束返回后，整个栈帧会被立即清空，其中的局部变量随之销毁。但在 JavaScript 中，请观察以下这段计数器代码：

function createCounter() {
  let count = 0; // 外部函数局部变量

  return function step() {
    count += 1;
    return count;
  };
}

const counterA = createCounter();
console.log(counterA()); // 示例输出：1
console.log(counterA()); // 示例输出：2

const counterB = createCounter();
console.log(counterB()); // 示例输出：1（独立的新环境）

按照直觉，createCounter() 在赋值给 counterA 时就已经执行完毕。然而当后续单独执行 counterA() 时，内部代码不但没有报错找不到 count，反而能够持续保留并累加其数值。同时，重新执行 createCounter() 得到的 counterB 拥有完全独立的计数空间，互不干扰。

这种“函数在执行时，依然携带着出生时的外部变量环境”的机制，正是闭包的核心表象。要从根本上理解为什么变量不会丢失，我们需要探究其底层基石：词法作用域与作用域链。

二、核心基石：词法作用域与作用域链层级

JavaScript 采用的是静态词法作用域（Lexical Scoping）。这意味着函数的作用域早在代码书写和词法解析阶段就已经被确定，而不是取决于函数最终在哪里被调用。

每个正在执行的函数都会对应一个词法环境（Lexical Environment），它由两部分组成：

• 环境记录（Environment Record）：具体存储当前作用域内声明的变量、函数和形参（例如 count: 0）。
• 对外部词法环境的引用（outer reference）：一个指向上一层词法环境的指针，作用域链就是由这些单向指针连缀而成的链表结构。

当内部函数 step 需要解析标识符 count 时，引擎会启动如下标识符解析流程：

1. 首先在当前 step 执行上下文的环境记录中查找，未找到 count。
2. 顺着自身 outerEnv 指针，向上到达 createCounter 的词法环境记录，找到 count，命中并完成读取或修改。
3. 如果外层仍未找到，会继续沿指针向上直至全局环境；若全局环境（outer: null）依然不存在，则抛出 ReferenceError。

三、形成机制：调用栈与堆内存四步推导

为什么外部函数出栈后，外层词法环境没有被垃圾回收机制（GC）清理？这是初学者最容易产生疑问的地方。现代 JavaScript 引擎（如 V8）在底层将环境记录分配在堆内存（Heap）中，并通过可达性算法（Reachability）决定变量寿命。

整个闭包的建立与执行经历了以下四个具体阶段：

1. 函数定义与环境分析

当 JavaScript 引擎编译 createCounter 时，发现内部嵌套了函数 step，且 step 内部使用了外层变量 count。引擎会标记该变量需要进行作用域提升捕获。

2. 外部函数执行并捕获作用域

调用 createCounter()，其执行上下文被压入调用栈。在创建内部函数 step 的实例时，引擎会给该函数对象赋予一个内部隐藏属性 [[Scopes]]。这个属性本质上是一个数组，按顺序记录了它所引用的外部作用域链（即当前 createCounter 的环境记录）。

3. 外部函数出栈与堆内存保留

createCounter() 执行完毕，返回 step 函数对象，其执行上下文从调用栈（Call Stack）弹出销毁。但是，返回的函数被全局变量 counterA 引用，而 counterA.[[Scopes]] 仍然牢牢持有 createCounter 的环境记录。

4. 内部函数在外部调用

当我们在外部执行 counterA() 时，引擎为其创建新的执行上下文，但该上下文的外部词法环境指针并不是指向当前的全局环境，而是直接指向创建时保存在 [[Scopes]] 中的堆环境。因此，count 变量不仅被访问，而且被安全地更新。

四、容易混淆的常见误区深度辨析

在实际开发与技术讨论中，关于闭包存在一些看似合理但容易产生偏差的认识，需要予以澄清。

误区一：“只有 return 一个内部函数才会产生闭包”

辨析：return 只是让内部函数跨越作用域传递到外部的最常见手段，但绝不是唯一手段。只要内部函数在另一个作用域中被引用并执行，且访问了外层词法作用域变量，它就是闭包。

例如在定时器、事件监听器或全局变量赋值场景中，完全不需要显式 return：

function setupAlert() {
  const message = "按钮被点击了";
  document.getElementById("myBtn").addEventListener("click", function() {
    console.log(message); // 这同样形成了闭包
  });
}
setupAlert();

setupAlert 执行结束后，DOM 节点的事件监听系统依然持有该回调函数引用，回调通过闭包保留了 message 变量。

误区二：“闭包保存的是变量创建那一刻的快照值”

辨析：闭包捕获的是变量本身（在内存中的引用），而不是变量值的副本或静态快照。

最典型的佐证就是经典的 var 循环问题（如图 3 所示）。由于 var 不具备块级作用域，循环体内创建的多个闭包全部指向同一份外层变量引用。当定时器回调延迟执行时，读取到的都是 i 循环结束后的最终值 3。而使用 let 时，JavaScript 引擎会为每一次循环迭代单独创建一个块级词法环境，每个回调各自绑定属于自身迭代的独立变量副本。

五、工程实用场景与内存安全管理

闭包是现代 JavaScript 框架与架构设计的基础设施，但也是无意中占用过多内存的常见来源。

1. 典型应用场景

2. 内存泄漏风险与正确释放

闭包本身是一种语言特性，保留外部变量是其预期行为，并不是“缺陷”。所谓的“闭包引起内存泄漏”，通常是指开发者已经不再需要该函数，但无意识地保持了全局引用或事件监听，导致相关联的庞大环境记录无法被垃圾回收。

function createLargeDataHandler() {
  const hugeData = new Array(1000000).fill("data"); // 大量内存占用

  return function process() {
    return hugeData.length;
  };
}

// 持有闭包引用，hugeData 无法被 GC
let handler = createLargeDataHandler();

// 当后续业务流程结束时，主动断开引用，释放内存
handler = null; // 切断全局引用链，V8 下次 GC 时将自动回收 hugeData

六、全文总结与理解心智模型

回顾全文，我们可以用一个清晰的心智模型来定义 JavaScript 闭包：

• 是什么：闭包是“函数”与“其诞生时所处的词法环境”打包形成的特殊对象。
• 为什么能存活：JavaScript 将函数内部引用的外层词法环境保存在堆中，只要内部函数仍处于全局可达引用链上，这部分堆内存就不会被垃圾回收器清除。
• 如何使用：合理利用闭包进行私有状态封装和逻辑复用；在长期运行的页面（如 SPA）中，对持有大内存闭包的变量或不再使用的事件回调，通过赋值 null 或移除监听器及时切断引用链。