闭包本身不导致内存泄漏，问题在于闭包被长期持有且捕获了不该驻留的大对象；应通过performance面板观察内存曲线、堆快照对比筛选(closure)、检查retaining tree及搜索全局变量/未解绑监听器/定时器/强引用缓存等高危模式来定位。
闭包本身不导致内存泄漏，问题出在“闭包被长期持有 + 捕获了不该留驻的大对象”。定位关键不是找闭包，而是找谁在拽着它、它又拽着谁。
看内存增长是否符合操作节奏
打开 Chrome Performance 面板，录制一段典型操作（比如打开/关闭模态框 5 次），重点关注内存曲线：
- 内存下限持续上移（每次操作后不回落）→ 强烈提示泄漏
- Nodes 或 Listeners 数量同步上升 → 很可能是事件监听器或 DOM 引用没清理
- GC 频繁但回收量小 → 堆里堆着大量“僵尸对象”，闭包很可能在其中
用堆快照揪出高嫌疑闭包
在 Memory 面板中执行以下动作：
- 操作前拍一张快照（Baseline）
- 重复触发疑似泄漏的操作（如组件挂载/卸载 3 次）
- 再拍一张快照，切换到 Comparison 视图
- 筛选 Constructor 为 (closure)，按 “# New” 或 “Retained Size” 排序
- 双击可疑闭包，看右侧 Retaining Tree：如果顶部是 window、document、全局 Map 或某个长生命周期实例（如 Vue 组件 this），就基本锁定源头
查代码里的典型高危模式
不用等快照，直接搜索这几类写法：
-
全局变量存函数：比如
window.handler = createHandler()，而createHandler内部引用了万级数组 -
事件监听器没配对解绑：尤其注意异步加载的模块中
addEventListener后遗漏removeEventListener -
定时器回调捕获 this 或 props：比如
setInterval(() => this.update(), 1000)，组件已销毁但定时器还在跑 - 缓存结构强引用闭包：用普通对象或 Map 缓存返回的处理函数，却没做失效清理或改用 WeakMap
快速验证是不是闭包惹的祸
临时加几行诊断代码，比快照更快：
- 在疑似函数内打点：
console.log('created with', largeData?.length)，看是否重复执行且不释放 - 手动触发 GC：
chrome.memory.gc?.()（仅 Chromium），然后观察内存是否下降 - 把闭包函数改成空函数：
return () => {}，再测内存——若不再涨，说明确实是闭包捕获的内容在作怪
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
