Memory面板不支持断点，需与Sources面板断点协同：先在生命周期钩子设断点→暂停后手动GC→拍堆快照→用Comparison视图分析Retaining Path→结合console.trace验证清理逻辑。
Memory 面板本身不支持断点，但它可以和 Sources 面板的断点协同使用，形成“触发—暂停—快照—比对”的闭环排查链。关键不是在 Memory 里设断点，而是用断点控制泄漏发生前后的精确时机，再配合手动 GC 和堆快照获取干净、可比的数据。
先在关键位置下断点，锁定泄漏发生节点
内存泄漏往往出现在状态切换、组件卸载、资源释放等生命周期钩子中。在这些逻辑入口处主动加断点，能确保你在对象本该被销毁的瞬间暂停执行：
- Vue 项目：在 beforeUnmount 或 onBeforeUnmount 函数第一行打上断点
- React 项目：在 useEffect 的清理函数内部（
return () => { /* 这里 */ }）第一行设断点 - 原生 JS：在调用 removeChild、element.remove() 或 clearInterval 前一刻打断点，观察变量是否还持有引用
断点暂停后，立刻手动触发 GC 再拍快照
断点停住时，JS 执行已暂停，但内存尚未回收。此时必须手动点击 Memory 面板右上角的 Collect garbage（小垃圾箱图标），强制运行一次垃圾回收，再点击 Take heap snapshot —— 否则快照里会混入大量本该被清掉的临时对象，干扰判断。
这个操作顺序不能颠倒：断点 → 手动 GC → 拍快照。尤其在组件刚卸载完、DOM 已移除但闭包仍存活的瞬间，这一步能帮你捕获到最真实的“残留对象”。
立即学习“Java免费学习笔记（深入）”；
用快照 Comparison 视图，顺着 Retaining Path 回溯断点处的引用
拍下两个快照（例如：进入页面后拍一张，断点停在卸载逻辑中并 GC 后再拍一张），切换到 Comparison 视图，筛选 # New 列明显增长的对象类型（如 (closure)、Detached HTMLDivElement）。双击可疑对象，在右侧 Retaining Tree 中逐层展开：
- 如果看到引用链终点是某个你刚在断点处看到的变量名（比如
timerId、handler、this._cache），说明它没被正确释放 - 若路径中出现
setInterval或addEventListener，而断点处本该调用clearInterval或removeEventListener却没执行，就定位到了泄漏源头
结合 console.trace 辅助验证断点上下文
在断点代码前一行插入 console.trace('unmounting, timerIds:', this.timerIds)，让控制台输出调用栈和当前状态。这样既能确认断点确实命中了预期逻辑，又能快速核对定时器 ID、监听器列表等关键清理目标是否为空或已清除。
如果 console.trace 显示 timerIds 仍有值，但后续 clearInterval 调用被跳过（比如因条件判断错误或异步时序问题），就能立刻意识到清理逻辑存在漏洞。
