闭包（Closure）是 JavaScript 中最重要的核心概念之一，也是理解高阶函数、模块化、异步回调等技术的关键。然而，许多开发者对闭包的理解停留在“函数套函数”、“能用外部变量”的表面，没有真正触及它的底层原理。本节将从形成条件和本质机制两个维度进行剖析。
闭包的形成条件
闭包并非某种特殊的语法结构，而是由特定代码写法自然触发的一种状态。一个典型的闭包需要满足以下三个条件：
- 函数嵌套
至少存在两层作用域：一个外部函数包含一个内部函数。外部函数创建了一个独立的作用域，内部函数定义在这个作用域内部。
- 内部函数引用外部函数的变量
内部函数访问了外部函数作用域中的某个变量（或形参）。这个引用让变量无法在外部函数执行完毕后被销毁。
- 内部函数被暴露到外部作用域
内部函数通过被返回、赋值给外部变量、存入数组或对象属性等方式，离开了它原本定义的作用域，在外部环境中被使用或被持有。
用一个最简单的例子验证这三个条件：
function outer() {
let count = 0; // 外部函数的变量
function inner() { // 函数嵌套
console.log(++count); // 引用外部变量
}
return inner; // 暴露到外部
}
const counter = outer(); // 拿到内部函数
counter(); // 1 // 在外部调用，闭包已形成
counter(); // 2在这个例子中，outer 执行完毕后，其执行上下文按理应被销毁，但 inner 被赋值给外部的 counter，而且 inner 还需要访问 count，因此 count 所在的变量环境被保留了下来——闭包就此形成。
闭包的本质是什么
闭包的本质可以用一句话概括：
闭包 = 函数 + 函数定义时的词法作用域链
在 JavaScript 中，函数不仅是一段可执行的代码，还是一个自带“环境”的实体。每次创建函数时，引擎会为它建立一个内部的 [[Environment]] 属性（或称为 [[Scope]]），指向该函数定义时所在的词法作用域链。当函数被调用时，一个新的执行上下文被推入调用栈，而这个新上下文的外层作用域引用会直接指向创建时保存的那条链，而不是动态依赖于调用位置。
换句话说，闭包让函数“记住”了自己的出生地，无论它被传送到哪里执行，都能沿着当初的链找到出生地的变量。
从内存角度看，这是因为外部函数的执行上下文虽然被移出调用栈，但其变量对象仍然因为内部函数的引用而无法被垃圾回收。这些本该消失的变量获得了一个延长的生命周期，成为只有内部函数才能访问的“私有”状态。
验证闭包的本质：词法作用域而非动态作用域
闭包遵循的是静态的词法作用域，而不是运行时决定的动态作用域。看下面这个测试：
var name = 'Global';
function outer() {
var name = 'Outer';
function inner() {
console.log(name);
}
return inner;
}
const fn = outer();
fn(); // 输出 'Outer'，而非 'Global'inner 在 outer 内部定义，它的作用域链上保存了 outer 的变量环境。尽管最终 inner 在全局作用域中被调用，但它仍然沿着自己创建时的链查找，找到了 outer 中的 name，而不是全局的 name。这就是词法作用域的体现，也是闭包机制的核心。
进一步理解：闭包不是“复制”变量
一个常见的误解是认为闭包会复制外部变量的值。实际上，闭包引用的是变量本身（在内存中的地址），而不是某个时刻的快照。来看一个循环中经常出错的例子：
for (var i = 1; i <= 3; i++) {
setTimeout(function() {
console.log(i);
}, i * 1000);
}
// 输出：4, 4, 4三个回调函数共享了同一个 i，因为 var 声明的变量提升到了函数作用域，闭包捕获的是变量 i 的引用。当定时器回调执行时，循环早就结束了，i 已经变成了 4。这种“变量共享”特性正是闭包导致的内存和逻辑问题的根源之一，但同时也是实现模块化、数据封装等高级模式的基础。
闭包的现实意义
理解闭包的形成条件和本质之后，你就能明白：
- 为什么事件处理器、回调函数、
setTimeout中能“记住”包裹它的变量。 - 为什么模块模式、高阶函数、函数式编程能够存在——它们都依赖闭包来保持私有状态。
- 为什么闭包既强大又危险：它强行延长了变量的生命周期，用得不好就容易引发内存泄漏。
在下一小节，我们将详细探讨闭包的内存表现、生命周期以及具体的应用场景与风险，让你能在实战中扬长避短。