排查闭包内存泄漏需用chrome devtools比对堆快照，重点关注closure对象异常增长及retained size偏高，通过retaining tree追溯持有者，结合sources断点验证捕获内容，并闭环清理后验证是否回落。
排查闭包导致的内存泄漏，核心是确认“谁在长期持有闭包”以及“闭包锁住了哪些不该留下的对象”。Chrome DevTools 是最直接、最权威的工具，整个流程围绕堆快照比对与引用链追溯展开，无需第三方插件或复杂配置。
用 Memory 面板录制并对比堆快照
这是定位泄漏的起点。关键不是看有没有闭包，而是看 Closure 对象是否异常增长或 Retained Size 偏高：
- 打开目标页面，按 F12 打开 DevTools，切换到 Memory 面板
- 勾选 Heap snapshot，点击 Take heap snapshot 拍下第一张（Baseline）
- 执行疑似泄漏的操作——比如反复打开/关闭一个弹窗、切换 SPA 路由、刷新数据列表
- 再次拍快照，共获得两张快照；在快照列表中选中第二张，右上角下拉菜单切为 Comparison 模式
- 在 Constructor 列筛选 Closure，重点关注 # New 和 Retained Size 明显上升的项
通过 Retaining Tree 追溯闭包的持有者
闭包本身不占多少内存，真正吃内存的是它捕获的大对象（如 DOM 节点、大型数组、组件实例）。Retaining Tree 能告诉你“谁不让它走”：
- 双击一个可疑的 Closure 条目，右侧自动展开 Retaining Tree
- 从顶部往下看第一级节点：若显示 window.myHandler，说明被全局变量强持；若显示 EventListener 且对应 DOM 已 Detached，基本可断定事件监听器未解绑
- 常见保留者包括：window、document、setInterval、Map.entries、WeakMap（注意：WeakMap 一般不导致泄漏，但 Map 会）
- 若发现某 Closure 被已移除的 HTMLDivElement 引用，直接点开该节点，再看它的 Retainers —— 很可能就是事件回调闭包在 hold 它
结合 Sources 与 Console 查看闭包实际捕获内容
快照只能看到“有引用”，看不到“引用了什么”。要确认闭包是否捕获了整棵 DOM 树或百万级数组，需动态验证：
- 在 Sources 面板中，找到生成该闭包的函数（如
createClickHandler、bindToComponent） - 在闭包定义行（如
return () => { ... }）设断点，刷新页面并触发逻辑 - 断住后，在 Console 中输入
console.dir(arguments.callee)或直接展开作用域面板里的 Scope → Closure - 检查是否捕获了
largeData、this.$el、canvas.getContext('2d')等大体积对象；如果只用id却捕获了整个user对象，就属于可优化点
交叉验证泄漏是否真实存在
避免把正常内存增长误判为泄漏。一次有效验证需闭环操作：
- 在疑似泄漏场景后，手动执行清理动作：清除定时器、移除事件监听器、将全局引用设为
null - 再次拍摄一张快照，与前一张做 Comparison
- 观察原可疑 Closure 的 # Deleted 是否大于 0、Retained Size 是否回落、其 Retainers 中是否不再出现 timer 或 Detached Element
- 若无变化，说明清理位置不对、变量名不一致，或清理逻辑根本没执行（比如组件卸载时 useEffect 清理函数未被调用）
