闭包本身不直接导致内存泄漏，但会延长其捕获变量的生命周期；高危场景包括未解绑的事件监听器、未清理的定时器、被全局/长生命周期对象持有的闭包，以及滥用缓存逻辑。
闭包本身不会直接导致内存泄漏，但它会让本该被回收的变量“活”得更久——只要闭包还存在，它捕获的外部变量就无法被垃圾回收器释放。真正出问题的是：闭包被长期持有，同时又无意中引用了大对象（比如 DOM 节点、大型数组、组件实例等），形成强引用链。
闭包延长变量生命周期的机制
JavaScript 的垃圾回收基于“可达性”：如果一个对象还能被代码中的某个变量或作用域访问到，它就不会被回收。闭包函数在创建时会绑定其词法环境，这个环境里所有被内部函数实际或潜在用到的变量，都会被保留在内存中。即使外层函数早已执行完毕，这些变量仍因闭包的存在而持续驻留。
例如：
- 一个返回闭包的函数内部创建了百万级数组，闭包哪怕只读取一次 length，整个数组也会被保留
- 多个闭包共享同一外部作用域（如共用 config、cache、largeData），只要其中一个闭包还活着，所有变量都动不了
必须警惕的四大高危场景
1. 事件监听器未解绑 + 闭包回调
闭包作为 addEventListener 的 handler 是最常见泄漏源。DOM 元素被移除后，若监听器未清除，闭包继续持有对元素及上下文数据的引用，整条链都无法释放。
2. 定时器未清理，闭包持续运行
setInterval 或 setTimeout 的回调是闭包时，尤其危险。组件卸载、页面跳转后定时器仍在执行，闭包内访问的 this、DOM、响应式状态全部卡在内存里。
3. 全局或长生命周期对象持有闭包
把闭包赋值给 window、模块导出对象、单例类属性，或者存进全局 Map 缓存，却没做淘汰或弱引用处理。一旦闭包捕获了大对象，它们就永久挂起。
4. 缓存逻辑滥用闭包保存实例引用
手动实现缓存（如用普通对象键名映射闭包函数）时，未校验缓存项有效性，也不限制大小。旧组件、旧数据对应的闭包一直被缓存结构强引用，无法 GC。
怎么快速定位是不是闭包泄漏？
打开 Chrome DevTools → Memory 面板 → 拍摄 Heap Snapshot。
操作前拍一张，反复触发疑似泄漏行为（如打开关闭同一组件 3 次）后再拍一张，用 Comparison 模式对比：
- 重点看 Detached DOM tree 是否异常增长
- 搜索 (closure)，按 Retained Size 排序，挑几个大的点开
- 顺着 Retainers 链往上查：它被谁引用？是 window？是 event listener？还是某个 timer 或 cache？
