闭包变量在无任何活引用时被自动回收；其驻留取决于是否“可达”——只要闭包被变量、事件监听器或定时器持有，捕获的外部变量就因引用链存在而无法释放，断开引用后即刻回收。
闭包本身不会“阻止”变量回收，真正起作用的是引用关系是否还存在。只要闭包函数还被某个变量、事件监听器或定时器持有，它所捕获的外部变量就始终“可达”，垃圾回收器就不会清理它们。
闭包让变量驻留的根本原因
JavaScript 垃圾回收基于“可达性”原则：一个变量只有在无法从根（如 globalThis、当前执行上下文、活跃闭包）通过引用链访问到时，才会被回收。闭包的特殊性在于，它会隐式保留对外层词法环境的引用。
- 外层函数执行结束时，其局部变量本该销毁，但若内部函数引用了这些变量，引擎会将它们移入堆内存，并与闭包绑定为一个“环境对象”
- 只要闭包函数本身仍被引用（比如赋值给全局变量、存入事件监听器、塞进数组），这个环境对象就一直可达
- 哪怕闭包只用到了 count，却可能连带保留整个 data 对象——因为捕获的是变量本身，不是它的某个属性
闭包变量何时会被真正回收
闭包变量不是永久存在的，它们的生命周期完全取决于是否有“活引用”。一旦断开，释放几乎是即时的。
- 把持有闭包的变量设为 null 或重新赋值（如 handler = null）
- 闭包定义在 IIFE 内部，且未向外暴露，函数执行完后整个上下文自然消亡
- 页面卸载、iframe 销毁，所有相关执行上下文和闭包一并清除
- 显式移除事件监听器（removeEventListener）或清除定时器（clearInterval）
常见误判与真实泄漏场景
闭包 ≠ 内存泄漏。问题不出在闭包机制本身，而出在“不该长期持有却一直持有”的设计。
立即学习“Java免费学习笔记（深入）”；
- 为多个 DOM 元素绑定事件时，用 var 声明循环变量，导致所有回调共享同一个变量，且整个作用域无法释放
- 全局变量长期引用一个携带大数组的闭包，而业务逻辑早已不再需要它
- 定时器回调持续引用已卸载的 DOM 元素，形成“幽灵引用”
- 缓存结构（如 Map、WeakMap 使用不当）中保存了闭包或其依赖的重型数据
验证与调试方法
靠直觉判断不可靠，需要用工具确认闭包是否还在占用资源。
- 在 Chrome DevTools 的 Memory 面板录制堆快照
- 先触发闭包创建（例如点击生成计数器实例）
- 再模拟“本该释放”的操作（如销毁组件、清空引用、移除监听器）
- 拍第二次快照，筛选类型为 Closure 的对象，对比数量和 retained size
- 若数量未减或 retained size 偏高，说明仍有隐式引用未切断，需顺着 retainers 路径定位源头
