在chrome devtools中用comparison视图定位内存泄漏，需先录制两次触发gc的代表性快照，再对比delta和size delta，按降序筛选持续增长的构造函数，检查retaining tree中全局变量、定时器、事件监听器或dom引用等持有者，最后通过多轮对比验证是否稳定递增。
在 Chrome DevTools 中，用内存快照的 Comparison 视图定位新增的泄漏对象，核心是「对比两次快照，聚焦增长量大且不该存在的对象」。关键不在于看绝对数量，而在于识别「本该被回收却持续增长」的实例。
1. 正确录制两个有代表性的快照
必须满足「可复现、有操作间隔、触发 GC」三个条件：
- 第一次快照：页面加载完成、执行一次手动垃圾回收（点击垃圾桶图标），然后立即拍下 Heap Snapshot #1
- 执行疑似引发泄漏的操作（例如：打开又关闭模态框 5 次、反复切换路由、绑定事件后未解绑就销毁组件）
- 再次手动触发垃圾回收（非常重要！否则临时对象干扰判断），再拍下 Heap Snapshot #2
2. 切换到 Comparison 视图并筛选关键列
在 Profiles（或 Memory）面板中，选中 #2 快照 → 右上角下拉菜单选择 Comparison → 对比目标选 #1。此时表格默认显示：
- # New：#2 中新增的实例数（减去 #1 中同类型存活数）
- # Deleted：#2 中已消失的实例数
- # Delta：净变化量（# New − # Deleted），重点看正数且数值大的行
- Size Delta：对应内存占用变化，配合 # Delta 看是否「量增 + 胀大」同时发生
3. 定位可疑对象的常用技巧
不要从顶层展开所有类，而是按以下顺序快速聚焦：
- 先按 # Delta 降序排列，拖动滚动条找顶部几十行中 # Delta > 0 且 Size Delta 明显增长 的构造函数名（如
MyComponent、CustomEvent、Array、Closure） - 点击该行左侧三角展开，看具体实例 —— 若显示
(array)或(closure)，右键 → Reveal in Summary view，回到 Summary 查看其 retaining tree - 重点关注「持有者链（retainers）」中是否包含：
• 全局变量（window、globalThis）
• 未清理的定时器（setTimeout/setInterval回调闭包）
• 事件监听器（addEventListener绑定后没调removeEventListener）
• DOM 引用（如缓存了已移除节点的parentNode、ownerDocument）
4. 验证是否真泄漏：重复操作 + 多轮对比
单次对比可能受 GC 时机影响，需交叉验证：
- 重复「操作 → GC → 快照」流程 3–4 轮，生成 #1、#2、#3、#4 快照
- 依次做 #2−#1、#3−#2、#4−#3 的 Comparison，观察同一构造函数的 # Delta 是否稳定递增
- 若每次操作后
MyService的 # Delta 都 +1，且 retaining tree 总指向某个全局 map，基本可确认泄漏点
