识别闭包内存泄漏的关键是闭包“不该活却一直活着”并拖住大对象，高危场景包括未清除的定时器、事件监听器和全局/缓存中未清理的引用。
识别闭包中的内存泄漏，关键不是看有没有闭包，而是看闭包是否“不该活却一直活着”，并拖着本该释放的大对象不放。定时器、事件监听器和未清理的引用，是三个最典型、最容易被忽略的高危场景。
定时器里的闭包在偷偷吃内存
setInterval 或 setTimeout 的回调函数一旦形成闭包，就会捕获外部变量。如果定时器没被清除，这个闭包就永远不会消失，它捕获的数据、DOM 节点、组件实例也就全卡在内存里出不去。
常见表现：
- 页面切换或组件卸载后，控制台仍在打印日志（比如轮询还在跑）
- 反复打开关闭同一功能模块，内存占用持续上升
- 闭包中直接用了 this、大型数组、响应式 store 实例等强引用对象
检查方法：在 Chrome DevTools 的 Memory 面板拍 Heap Snapshot，筛选 (closure)，再点开看它的 Retainers —— 如果发现被某个 Timer 持有，基本就是它了。
事件监听器绑得容易，解得难
用 addEventListener 绑定一个箭头函数或内联闭包时，它天然捕获了外层作用域的所有变量。一旦 DOM 元素被 remove()，但监听器没调用 removeEventListener，闭包仍通过事件系统被全局持有，导致整个作用域链无法回收。
特别危险的情况：
- 在 React/Vue 组件中绑定监听器，但没在 useEffect / onUnmounted 里清理
- 监听器是匿名函数，根本没法传给 removeEventListener
- 元素被移入 Shadow DOM 或 iframe 后，监听器被遗忘
快速验证：选中目标元素 → 右键 “Break on” → “attribute modifications”，看是否还有事件监听器残留；或者用 Elements 面板的 Event Listeners 标签页 直接查看。
未清理的引用：闭包只是帮凶，全局/缓存才是主谋
闭包本身不致命，真正让它变成内存黑洞的，是它被长期持有的位置——比如挂到了 window 上、存进了模块级 Map、塞进了单例类的属性里，或者被某个永远不销毁的对象（如路由守卫、WebSocket 实例）悄悄引用着。
典型信号：
- 关闭页面前手动把某个变量设为 null，内存明显回落
- 快照对比中，“Closure” 类别下出现大量相同结构、Retained Size 很高的条目
- 缓存对象（如 Map）size 持续增长，且 key 是 DOM 节点或组件实例
建议优先用 WeakMap 存储 DOM 关联数据，或用 FinalizationRegistry 配合 WeakRef 主动感知对象是否已被回收，而不是靠人工“记得清理”。
