闭包“记”的是被内部函数实际引用的外层变量，而非整个作用域；v8 会释放未使用的捕获变量，但开发者需主动清理事件监听器、定时器及全局引用以避免内存泄漏。
闭包到底在“记”什么？
闭包不是某种特殊函数，而是函数与其定义时词法环境的绑定结果——只要一个内部函数引用了外层函数的变量，并且这个内部函数在外部被保留（比如作为返回值、赋给事件监听器、塞进定时器），JS 引擎就会让那些被引用的变量继续留在内存里，哪怕外层函数早就执行完了。
关键点在于：不是整个外层作用域都被“冻结”，只是被实际用到的变量会被保留。现代 V8 引擎能识别未使用的捕获变量并释放它们，但无法判断你“逻辑上是否还需要”，这得靠人来把关。
-
var声明的循环变量容易被所有闭包共享，导致点击 10 个按钮全输出10 - 用
let或显式传参（如((idx) => () => console.log(idx))(i)）可隔离每次迭代的值 - 闭包中无意持有
DOM节点、大数组、XMLHttpRequest实例，会直接拖住整块内存
哪些场景最容易悄悄吃掉内存？
闭包本身不泄漏，但和 DOM、定时器、全局引用一结合，就很容易触发“可达但无用”的状态——垃圾回收器看到还有引用，就不敢动，而开发者以为它早该没了。
-
addEventListener绑定的回调若捕获了大对象（比如const data = new Array(1e6)），即使元素被remove()，只要监听器没手动removeEventListener，data就一直卡在内存里 -
setInterval回调形成闭包后长期存活，里面哪怕只引用了一个没用的变量，也会让整个外层作用域活下来 - 把闭包赋给全局变量（如
window.handler = function() { ... }）或模块顶层变量，等于给变量加了“永久锁”
怎么确认是不是闭包导致的内存问题？
别猜，用 Chrome DevTools 的 Memory 面板拍快照对比：
立即学习“Java免费学习笔记（深入）”；
- 先触发疑似泄漏的操作（比如反复打开关闭某个弹窗）
- 点 Capture heap snapshot，选 Summary 视图，筛选
Closure构造函数 - 看有没有异常多的闭包实例，点进去查它的
retained size和持有的对象（比如大量Array或HTMLDivElement） - 再点 Retainers 标签，看谁在引用它——是事件监听器？还是某个未清理的
setTimeout？
如果发现某闭包持有一个本不该长期存在的 DOM 节点，基本就能定位了。
真正管用的清理手段有哪些？
不是写完闭包就完事，得主动断链。重点不是“避免闭包”，而是“控制它的生命周期”。
- 事件监听器必须配对使用：
element.addEventListener('click', handler)→ 后续要element.removeEventListener('click', handler)；不能用匿名函数 - 定时器记得
clearTimeout/clearInterval，尤其在组件卸载（如 React 的useEffectcleanup）、页面跳转前 - 不再需要闭包时，显式切断引用：
handler = null，或从对象属性中delete obj.handler - 需缓存私有数据又怕影响回收？优先用
WeakMap，它的键名对象被回收时，对应条目自动消失
最常被忽略的一点：闭包捕获的是变量的“引用”，不是值。哪怕你只打算读一个 ID，也别把整个 user 对象传进去——拆出 userId 再闭包，内存压力立刻小一截。
