闭包是函数记住其定义时词法作用域的机制，表现为内部函数可访问外部变量；常用于封装私有状态、柯里化等，但不当使用易致内存泄漏或React中读取旧值。

闭包就是函数记住了它定义时的词法作用域

闭包不是特殊语法，而是 JavaScript 中函数的一类行为表现：当一个内部函数被返回或传递到外部作用域后，仍能访问其定义时所在作用域中的变量，这就形成了闭包。关键点在于“定义时的作用域”，而不是“调用时的作用域”。

常见错误现象：for 循环中用 var 声明计数器，再在定时器里打印 i，结果全输出 5（假设循环 5 次）——这是因为所有回调共享同一个 i 变量，而循环结束时 i 已是 5。用闭包可解决：

for (var i = 0; i < 5; i++) {
  (function(j) {
    setTimeout(() => console.log(j), 100);
  })(i);
}

或者更现代写法：let 块级绑定天然形成独立作用域，本质也是靠闭包机制支撑。

闭包常用于封装私有状态和延迟求值

JavaScript 没有真正的私有字段（ES2025 #field 是语法糖，底层仍依赖闭包逻辑），所以闭包是实现数据隐藏最直接的方式。

• 模块模式：返回一个对象，其方法可访问外层函数的局部变量，但外部无法直接修改这些变量
• 工厂函数：如 createCounter() 每次调用都生成一组独立的 count 状态
• 柯里化/偏函数：预置部分参数，剩余参数留待后续调用，中间状态靠闭包维持

示例：

function createCounter() {
  let count = 0;
  return {
    increment() { count++; },
    value() { return count; }
  };
}
const c1 = createCounter();
c1.increment();
console.log(c1.value()); // 1

这里 count 对外界不可见，只能通过返回的对象方法操作，这就是闭包提供的封装能力。

闭包容易引发内存泄漏的两个典型场景

闭包本身不等于内存泄漏，但若引用了本不该长期存活的大对象（比如 DOM 节点、大数组），又没及时释放，就会阻止垃圾回收。

• setTimeout / setInterval 回调中持有对外部大对象的引用，且定时器未清除
• 事件监听器中使用匿名函数闭包，又忘记用 removeEventListener 解绑

例如：

function attachHandler(element, data) {
  element.addEventListener('click', function() {
    console.log(data.largeArray.length); // data 被闭包捕获
  });
}
// 如果 element 被移除，但监听器未解绑，data 就一直无法被 GC

解决办法：用具名函数 + 显式解绑，或使用 AbortController（现代浏览器）控制监听器生命周期。

React 中的闭包陷阱：useEffect 里读取 state 或 props 的旧值

这是前端开发中最常踩的坑之一。因为 useEffect 内部的回调函数在组件某次渲染时被定义，它捕获的是那次渲染时的 state 和 props 值。

典型表现：useEffect 里发起请求，成功后更新状态，但回调里读到的仍是初始值；或定时器里始终看到旧的 count。

解决方案取决于需求：

• 需要最新值 → 用 ref 手动同步，并在闭包中读 ref.current
• 需要响应变化 → 把依赖项加入 useEffect 依赖数组，让 effect 重新执行
• 需要“快照”语义（如防抖、动画帧）→ 保留闭包行为，这是有意为之

本质上，这不是 React 的 bug，而是 JavaScript 闭包机制的自然体现 —— 只是 React 把这个特性暴露得更频繁、更明显。

闭包的核心复杂点从来不在“怎么写”，而在于“什么时候该让它存在，什么时候该切断引用”。多数问题出在对变量生命周期缺乏显式控制，而非不理解定义。