chrome内存快照对比需“操作→清理→再测量”闭环：先gc、执行目标行为、确保清理逻辑运行、再gc后拍第二张快照；comparison中按constructor或retained size排序找增长对象，retainers链终点为window/map/未清除定时器即泄漏；dominator tree中高retained size的closure/object/array及其dominator指向模块名可定位源头；三次快照线性增长且retained size不回落即确认泄漏。
Chrome 内存快照的对比功能本身不自动标出“问题点”，但能高效暴露异常增长的对象类型和引用关系。关键在拍得准、比得对、看得深。
选对时机拍两张快照
不是随便点两次“Take snapshot”就有用。必须形成“操作→清理→再测量”的闭环：
- 首次快照前，先点 Memory 面板左上角垃圾桶图标手动触发 GC，清掉临时对象干扰
- 执行一次完整目标行为（比如打开又关闭一个弹窗、加载并卸载一个图表模块）
- 确保清理逻辑已运行：调用 dispose()、移除事件监听器、清空定时器、将大引用设为 null
- 再次 GC 后立即拍第二张快照
用 Comparison 视图聚焦增长对象
在 Memory 面板中选中第一张快照，按住 Ctrl（或 Cmd）再点击第二张，点击右上角 “Comparison” 按钮：
- 按 Constructor 排序，重点关注带红色加号（+）的行：如
AnalyticsTracker、AdManager、ChartView等自定义构造函数，数量持续增加就是强信号 - 按 Retained Size 排序，找那些大小稳定在几 MB 以上、且两次快照间几乎没下降的对象
- 展开某一行，点击任意一个实例 → 右侧切换到 Retainers 标签页，从上往下看引用链：终点如果是
window、globalThis、长期存活的Map或未清除的setTimeout回调，基本可确认泄漏源头
结合 Dominator Tree 快速定位大内存持有者
切换到 Dominator Tree 视图，按 Retained Size 降序排列：
- 顶部几行里如果出现 Closure、Object、Array 类型，且 Retained Size 明显偏高（≥500 KB），优先点开
- 点开后看它的直接 dominator 是谁——往往就是那个意外持有了大量子对象的闭包或全局缓存
- 若 dominator 是某个你写的模块名（如
UploadService），就说明这个模块内部存在未释放的引用链
验证是否真泄漏：加第三张快照
重复同样操作 2–3 次后拍第三张快照，与第一张做 Comparison：
- 如果某类对象（如
Detached HTMLDivElement或Closure）数量线性增长（+1、+1、+1），而 Retained Size 不回落，泄漏基本坐实 - 若增长只出现在第一次操作后，后续持平，可能是初始化开销，不算泄漏
- 配合开启 “Record allocation stack traces”，能直接看到新增对象在哪一行代码 new 出来，快速回溯到源文件
