闭包本身不是内存泄漏，问题在于它长期持有本该释放的大对象；常见高危场景包括未解绑的事件监听器、长期运行的定时器回调、无限堆积的缓存型闭包及类方法中隐式捕获过多变量。
闭包本身不是问题，问题在于它无意中长期持有本该释放的大对象。只要闭包还存活，它捕获的变量就无法被垃圾回收（GC），哪怕这些变量早已不用。
哪些闭包场景容易引发泄漏
常见高危模式有这几类：
- 事件监听器里的闭包没解绑：比如给按钮绑定点击回调，回调里用了外层的大数组或 DOM 元素；即使按钮被移除，只要监听器还在，闭包就一直拖着这些对象不放
- 定时器回调长期运行：setInterval 里直接引用了外部的 logBuffer、config 或整个 Vue 实例，buffer 不断追加又不清空，实例卸载后仍被定时器强引用
- 缓存型闭包无限堆积：用 Map 或普通对象做缓存，每次调用都塞新数据，但没设上限、没淘汰策略、也没手动清理
- 类方法注册时隐式捕获 this 和参数：像 registerEvent(() => handler(data)) 这种写法，闭包会同时捕获 callback、this.handlers、传入的 config 等——哪怕只用到其中一小部分，整套引用链都得留着
怎么用 Chrome DevTools 排查
关键不是看闭包有多大，而是看它不该持有时还在持有什么：
- 在 Memory 面板拍下堆快照，切到 Constructor 视图，筛选 Closure
- 点开可疑 Closure，右侧看 Scope：里面列出它捕获的所有变量，重点关注 hugeArray、responseJson、document.getElementById(...) 这类明显的大对象或 DOM 节点
- 再看 Retainers：如果显示被 window、全局 Map、未清除的 setInterval 或长期存在的事件监听器引用，说明生命周期失控
- 做对比分析：操作前拍一次，反复触发疑似泄漏动作（如打开关闭弹窗）后再拍一次，用 Comparison 视图看 Closure 的 # New 是否持续为正——每次都是新增且不销毁，基本就是泄漏
- 拍快照前先点垃圾回收图标强制 GC，如果 GC 后 Closure 仍稳稳挂着大对象，那就不是临时驻留，是真实泄漏
修复思路很直接：切断不该有的引用
定位到问题代码后，针对性处理：
- 事件监听器要配对 removeEventListener，尤其在组件卸载、元素移除时
- 定时器记得保存 id，用 clearInterval 清理；或者改用 requestIdleCallback 等更可控的方式
- 缓存加限制：用 LRU 策略、设置最大条目数、定期清理过期项，别让 Map 无节制增长
- 避免在闭包里“全量捕获”：把大对象中真正需要的字段提前抽出来，比如 const id = config.id; return () => console.log(id)，而不是直接闭包引用整个 config
- 必要时主动释放：closure = null，让 GC 知道这个引用可以断了（前提是确认没有其他地方还在用）
不复杂但容易忽略
