闭包通过维持引用链使变量保持“可达”而持续存活；只要闭包被全局变量、事件监听器、定时器或数据结构等活引用持有，其捕获的变量就无法被垃圾回收，需主动断开引用或改用弱引用机制来释放。
闭包引用本身不破坏垃圾回收机制，但会改变变量的“可达性”，从而决定哪些对象能被回收、哪些必须长期驻留。
闭包如何让变量持续存活
普通函数执行完，局部变量通常立即不可达；但若内部函数引用了这些变量，引擎会把它们移到堆内存，并与闭包绑定为一个词法环境对象。只要这个闭包还被某个活跃引用持有（比如赋值给全局变量、作为事件处理器、存进数组），整个环境对象就始终“可达”——垃圾回收器从根（如 window 或当前执行上下文）出发能顺引用链访问到它，就不会清理。
- 即使只用到了 count，也可能连带保留外层整个 data 对象，因为闭包捕获的是变量本身，不是它的某个属性
- 闭包中引用 DOM 元素时，该元素及其父级树结构也会因引用链存在而无法释放
- 循环中用 var 声明变量并创建闭包，会导致所有回调共享同一个变量，且整个作用域无法退出
哪些情况会让闭包变量无法回收
关键不在闭包是否存在，而在它是否还被“活引用”。以下情形都会阻止回收：
- 闭包被赋值给全局变量或模块顶层导出值，长期存在于模块作用域中
- 作为事件监听器绑定在 DOM 上，但未调用 removeEventListener 解绑
- 被 setInterval 或 setTimeout 持续调用，定时器未清除
- 存入 Map、Array 等数据结构后未清空或淘汰
- 在 ES 模块中导出闭包，且该模块被其他活跃模块 import 后长期持有
怎样让闭包变量及时释放
回收条件很明确：断开所有强引用路径。操作上可主动干预：
- 不再需要时，把持有闭包的变量设为 null 或重新赋值（如 handler = null）
- 事件监听器用完立刻移除，定时器结束立即清除
- 缓存类场景改用 WeakMap 存储依赖项，避免强引用阻碍回收
- 只捕获真正需要的数据，用显式参数传入代替直接引用大对象（例如传 id 而非整个 user 对象）
- 借助 Chrome DevTools 的 Memory 面板拍堆快照，筛选 Closure 类型，查看 retainers 路径确认谁在持有它
闭包不是内存泄漏的根源，而是放大器
闭包机制本身完全正常。问题出在设计层面：本该短期存在的闭包被意外长期持有，或闭包中无意维持了重型对象的引用。真正的泄漏来自“不该持有时却一直持有”，而不是闭包语法本身。理解引用链走向，就能预判变量生命周期，写出更可控的代码。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
