通过堆快照对比识别内存泄漏：操作前拍基线快照，重复操作并手动gc后拍对比快照，聚焦“# new”列中业务类名或closure的持续增长项，沿retaining path追溯至未清理的事件监听器、闭包引用或缓存结构，修复后验证新增数趋零且堆大小稳定。
通过堆快照（Heap Snapshot）发现未回收对象，核心是识别本该被 GC 回收却长期驻留内存的对象，尤其是那些意外被闭包、事件监听器、全局变量或缓存结构持续引用的实例。
抓取时机要选对：在疑似泄漏后立即拍快照
不要在页面刚加载时拍，也不要在操作中途随意拍。正确做法是：
- 执行一段可复现的操作（比如打开又关闭某个模块 5 次）
- 等待几秒，让浏览器有机会触发 Minor GC（V8 中通常自动进行）
- 手动触发一次“垃圾回收”（DevTools 的垃圾桶图标 ✅）
- 立刻拍下堆快照（Capture Heap Snapshot）
这样能过滤掉临时对象，让残留的“不该存在”的对象更明显。
用“Comparison”模式对比快照，聚焦增长项
单独看一个快照很难判断是否泄漏；关键靠对比：
- 拍 snapshot #1（操作前基线）
- 执行操作并重复多次（如反复创建/销毁组件）
- 触发 GC 后拍 snapshot #2
- 在 DevTools 中切换到 “Comparison” 视图，选择 #2 对比 #1
重点关注 “# New” 列数值大、且 Constructor 名称是你业务代码中的类名（如 ModalManager、ChartInstance）或闭包（Closure）的条目。如果某类对象每次操作后都新增 1 个且不减少，基本就是泄漏点。
顺着 retaining path 追根溯源，找强引用链
在 Comparison 视图中点击可疑构造函数（如 MyComponent），右侧会显示所有实例。选中一个实例 → 点击 “Retainers” 标签 → 查看完整的引用链（retaining path）：
- 顶部通常是 GC root（如 window、global、DOMWindow）
- 往下逐层看谁持有了它：是不是某个未移除的 addEventListener？
- 是不是闭包中捕获了外部作用域的数组，而该数组又 push 了这个对象？
- 是不是 Map/Set 缓存没清理，key 是 DOM 节点但 value 是组件实例？
真正泄漏往往卡在第 3～5 层 —— 看似无关的中间变量（比如一个叫 pendingTasks 的全局数组），其实一直 hold 着你认为已销毁的对象。
验证修复：改完代码后重跑对比流程
修复后别只看“对象没了”，要闭环验证：
- 用同样操作步骤再跑 5 轮
- 每次 GC 后拍快照，做新对比
- 确认该构造函数的 “# New” 基本为 0，或波动在 1～2 个（属正常抖动）
- 同时观察总体 JS heap size 是否趋于平稳（不持续上涨）
如果 retaining path 里还出现你的模块名，但路径终点变成了 WeakMap 或已加 removeEventListener，说明引用已被正确切断。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
