闭包是JavaScript中函数记住其词法作用域的机制，广泛用于事件监听、模块封装、防抖节流等场景；其核心是内部函数引用外部变量导致后者无法被GC，易引发内存泄漏。
JavaScript 中闭包不是“要不要用”的问题，而是你已经在用、只是没意识到它在起作用——比如事件监听器里访问外部变量、模块私有状态封装、防抖节流函数的计时器引用，全依赖闭包。
闭包怎么形成的：函数记住了它的词法作用域
当一个函数被定义在另一个函数内部，并且内部函数在外部函数返回后仍被调用，JS 引擎就会保留外部函数作用域中被内部函数引用的变量。这不是魔法，是引擎对 [[Environment]] 内部属性的维护。
常见错误现象：for (var i = 0; i console.log(i), 100); } 输出三个 3——因为所有回调共享同一个 i 变量，而循环结束时 i 已是 3。改用 let 或闭包包裹可解决：
for (var i = 0; i < 3; i++) {
(function(i) {
setTimeout(() => console.log(i), 100);
})(i);
}
闭包的真实使用场景：私有数据 + 延续生命周期
闭包最不可替代的作用是模拟“私有变量”。ES6 的 #privateField 是语法糖，底层逻辑仍靠闭包或 WeakMap 实现。
- 模块模式：用立即执行函数返回对象，只暴露方法，不暴露状态变量
- 柯里化函数：
const add = x => y => x + y中
，
y => x + y就是一个闭包，捕获了x - 事件处理器中保存配置：
button.addEventListener('click', () => handleClick(config))，只要config不被 GC，它就一直可用
闭包的代价：内存泄漏比你想象中更常见
闭包会让变量无法被垃圾回收，尤其在 DOM 节点和事件监听器长期共存时。典型错误：
- 给全局 DOM 元素绑定回调，回调里引用了大对象（如整个
data数组），而元素未被移除 → 数据一直驻留 - 定时器未清理：
const timer = setInterval(() => console.log(state), 1000)，只要timer活着，state就不会释放 - 控制台调试时意外保留引用：Chrome DevTools 中打印过某个闭包函数，再刷新前它可能还挂在 console 上
检测方式：用 Chrome DevTools 的 Memory 面板拍快照，筛选 Closure 类型，看哪些变量本该释放却仍在。
箭头函数和闭包的关系：它不改变作用域规则，只省略 function 关键字
箭头函数没有自己的 this、arguments、super 或 new.target，但它照样形成闭包——只要它引用了外层作用域变量。
例如：const createLogger = prefix => msg => console.log(`[${prefix}] ${msg}`) 返回的箭头函数就是闭包，捕获了 prefix。但注意：它不能用 call/apply 改变 this，这点和普通函数闭包不同。
容易踩的坑：setTimeout(() => this.doSomething(), 100) 中的 this 来自外层，如果外层 this 是 undefined（严格模式下），就会报错——这不是闭包的问题，是 this 绑定规则被误读。
真正难的是判断“这个变量到底会不会被回收”，而不是“怎么写个闭包”。多数内存问题，根源不在闭包本身，而在忘记切断引用链。
