闭包是函数记住其定义时词法作用域的机制，表现为内部函数可访问外部变量；常用于封装私有状态、柯里化等，但不当使用易致内存泄漏或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 没有真正的私有字段（ES2022 #field 是语法糖，底层仍依赖闭包逻辑），所以闭包是实现数据隐藏最直接的方式。
立即学习“Java免费学习笔记（深入）”；
- 模块模式：返回一个对象，其方法可访问外层函数的局部变量，但外部无法直接修改这些变量
- 工厂函数：如
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 把这个特性暴露得更频繁、更明显。
闭包的核心复杂点从来不在“怎么写”，而在于“什么时候该让它存在，什么时候该切断引用”。多数问题出在对变量生命周期缺乏显式控制，而非不理解定义。
