闭包不会被轻易回收，是因为它使变量持续可达；javascript采用标记-清除gc策略，从根对象出发追踪引用链，只要闭包及其捕获的变量仍被全局变量、事件监听器或定时器持有，就始终标记为活跃并免于回收。
闭包不会被轻易回收，不是因为它有特殊身份，而是它让变量持续“可被访问”——垃圾回收器只看引用链是否断开，不看代码是不是写了 function。
标记清除法才是判断依据
JavaScript 引擎（如 V8）用的是标记-清除（Mark-and-Sweep）GC 策略，核心逻辑很朴素：
- 从根对象（global、当前调用栈、DOM 节点等）出发，顺着所有引用往下找
- 凡是能被“走到”的对象，打上标记，视为“活跃”
- 没被标记的，就是垃圾，下次 GC 就清理掉
闭包本身不是一种特殊数据类型，引擎不会给它贴个“闭包标签”然后绕着走。它只是普通函数对象，但这个函数对象的 作用域链里存着对外层变量的引用。只要这个函数还被某个变量、事件监听器或定时器拿着，它所依赖的外层变量就天然“可达”，自然逃过清除。
闭包让变量“活下来”的真实链条
真正起作用的，是一条隐性的引用链：外部变量 → 闭包函数的作用域 → 闭包函数本身 → 外部持有者（比如全局变量、事件回调、定时器）。
-
只捕获实际用到的变量：引擎很聪明，不会把外层所有局部变量都塞进闭包。比如内部函数只读
count，那bigData和temp在外层函数执行完后立刻可回收 - 变量不在栈里，挪到堆里和闭包绑定：原本该随函数退出销毁的局部变量，因被闭包引用，被提升为堆内存中的“环境对象”一部分
-
断掉任意一环，整条链就失效：把持有闭包的变量设为
null，或移除事件监听器，或清空定时器，引用链断裂，下一次 GC 就能回收整个环境
常见“以为能回收，其实没断链”的情况
很多问题不是闭包本身有问题，而是开发者没意识到引用还在悄悄维持着。
- 给 DOM 元素绑了闭包回调，元素已删除，但没调
removeEventListener - 把闭包赋给了全局变量或模块级变量，后续没主动置空
- 用
setInterval持续运行一个闭包，而闭包里又引用了大数组或 DOM 节点 - 闭包里保存了
this或整个组件实例，又没在组件卸载时清理
验证和辅助回收的关键动作
不用手动触发 GC，但可以帮它做判断：
- 用 Chrome DevTools 的 Memory 面板拍两次 Heap Snapshot，筛选
Closure类型，对比Retained Size和Retainers链，看谁在拽着它不放 - 主动切断引用：赋值
myHandler = null、调用element.removeEventListener、清除clearInterval - 避免把闭包和大对象（如
canvas.getContext('2d')、大型 JSON）长期绑定，尤其不要缓存在全局或静态结构中
闭包不是内存泄漏的罪魁，而是暴露引用管理漏洞的镜子。搞懂 GC 怎么数引用，就等于看清了闭包何时该走、为何赖着不走。
