闭包本身不等于内存泄漏，真正危险的是它“不该存在却一直存在”并拖住大对象；高危场景包括未清除的定时器、未解绑的事件监听器和挂载在全局变量中的未清理引用。
闭包本身不等于内存泄漏，真正危险的是它“不该存在却一直存在”，并拖着本该释放的大对象——比如大型数组、DOM 节点、组件实例或响应式 store。定时器、事件监听器和全局变量，是三个最常见、最容易被忽略的高危入口。
定时器：轮询没停，数据就出不去
setInterval 或 setTimeout 的回调函数一旦形成闭包，就会捕获外部作用域里的变量。如果定时器没被清除，这个闭包就永远存活，它引用的数据也跟着卡在内存里。
- 典型表现：页面切换后控制台还在打印日志；反复打开关闭同一模块，内存占用持续上涨
- 高危写法：闭包里直接用了 this、大型数组、store 实例等强引用对象
- 检查方法：Chrome DevTools → Memory → Heap Snapshot → 筛选 closure → 查看 Retainers，若显示被 Timer 持有，基本就是它
- 建议：保存 timer ID，组件卸载前调用 clearInterval/clearTimeout；避免在回调里持有大对象，改用 ID 或轻量标识
事件监听器：绑得快，忘得更彻底
addEventListener 绑定的箭头函数或内联函数，天然形成闭包，捕获外层所有变量。DOM 元素被 remove() 后，若没调用 removeEventListener，闭包仍通过事件系统被全局持有，整个作用域链无法回收。
- 特别危险：React/Vue 中在 useEffect/onUnmounted 里漏掉清理；监听器是匿名函数，根本没法传给 removeEventListener
- 快速验证：Elements 面板 → 选中元素 → Event Listeners 标签页，看是否残留；或右键 “Break on → attribute modifications” 触发断点
- 建议：优先用 AbortController.signal（现代标准）；复杂场景改用事件委托；绑定时尽量避免闭包捕获大对象
全局变量：挂上去容易，摘下来没人管
闭包只是“搬运工”，真正让它变成内存黑洞的，是它被长期挂载的位置——比如 window 上、模块级 Map 里、单例类属性中，或者被 WebSocket、路由守卫这类长生命周期对象悄悄引用着。
- 典型信号：手动把某个变量设为 null 后内存明显回落；Heap Snapshot 中 Closure 类别下出现大量同结构、Retained Size 很高的条目
- 缓存风险：Map size 持续增长，且 key 是 DOM 节点或组件实例
- 建议：优先用 WeakMap 存 DOM 关联数据；缓存加 TTL 或绑定 disconnect 回调；避免把函数和大数据一起缓存，按需重建闭包
