使用chrome devtools memory面板拍堆快照，筛选closure类型，通过对比快照delta、分析retainers链和closurescope定位内存泄漏源头，并手动清理验证。
直接用 Chrome DevTools 的 Memory 面板拍堆快照，筛选 Closure 类型，重点看 Retained Size 大、重复出现、或关联 Detached DOM 的闭包实例——它们大概率就是没被释放的“内存锚点”。
拍两次快照做对比
在疑似泄漏操作前拍一次（Snapshot 1），执行操作（比如打开又关闭一个弹窗、刷新列表、切换路由）后再拍一次（Snapshot 2）。切换到 Comparison 视图，按 Delta 列排序，重点关注新增的 Closure 实例。如果某类闭包在 Snapshot 2 中数量明显增加、且 Retained Size 稳定在几百 KB 甚至几 MB 以上，就要盯住它。
顺着 Retainers 链往上查引用源头
点击一个可疑闭包 → 右侧展开 Retainers 面板 → 逐级点开引用路径。关键线索包括：
- 看到 Closure → Context → Variable → hugeStr：说明这个闭包正强持有大字符串，外部已无其他引用，但它卡住了整块内存
- Distance 值很大（比如 ≥5）：表示它离 GC 根（如 window、document）很近，GC 很难触达，基本不会被自动回收
- 路径中出现 EventListener、setTimeout、Promise.then：对应常见泄漏场景，比如监听器未解绑、定时器 ID 丢失、Promise pending 不结束
结合 Scope 面板确认捕获内容
在快照里双击该闭包 → 展开 ClosureScope → 查看它实际捕获了哪些变量。这里能直观看到：
- 是否捕获了本不该长期存在的对象（如已卸载组件的 this、大 JSON 数据、Base64 图片字符串）
- 变量值是否为 null/undefined 但依然被持有（说明逻辑上已失效，但引用没断）
- 是否有意料之外的 DOM 节点（尤其类型为 HTMLDivElement 但 parentNode 为 null）
验证是否真泄漏：手动清理再测
别只看快照就下结论。要验证，得主动干预：
- 在控制台执行 removeEventListener 或 clearTimeout(id)，再拍第三张快照，看对应闭包是否消失、Retained Size 是否回落
- 把疑似闭包引用设为 null（如 myHandler = null），然后点 DevTools Memory 面板里的 Collect garbage 按钮强制触发 GC
- 配合 console.memory.usedJSHeapSize 打印前后数值，观察增长是否收敛
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
