Chrome DevTools内存快照定位JS内存泄漏的关键在于对比操作前后快照：在典型操作（如打开/关闭模态框）前、主动清理后、重复操作后分别拍摄，通过Comparison模式按Constructor或Retained Size排序，重点关注红色新增对象、大且不降的Retained Size及Retainers引用链，结合DOM残留、未清定时器、事件监听器、Map/Set缓存等典型泄漏特征，并辅以分配堆栈追踪、Performance录制和手动gc验证。
Chrome DevTools 的内存快照（Heap Snapshot）是定位 JavaScript 内存泄漏最直接有效的手段之一。关键不在于“拍多少张”，而在于“怎么比”和“怎么看”。
什么时候该拍快照？
在疑似泄漏的典型操作前后各拍一张：比如打开一个模态框、进入某页面、执行一次数据加载，再关闭/离开/清空——此时若内存没回落，就值得怀疑。
- 首次快照（Baseline）：操作前，确保界面空闲、无动画、无定时器活跃
- 第二次快照：完成操作并主动清理后（如调用 dispose、removeEventListener、清空引用）
- 可追加第三张：重复操作几次后再拍，观察某类对象是否持续增长
如何对比快照找线索？
在 Memory 面板中选中两张快照 → 点击右上角 “Comparison” → 按 Constructor 或 Retained Size 排序。重点关注：
- 红色行（+）：新增对象，尤其是你代码里自定义的类（如 ChartView、DataProcessor）数量异常增加
- Retained Size 大且稳定不降：说明它被某个长生命周期对象持有着，比如全局变量、未清除的事件监听器、闭包中意外捕获的 DOM 引用
- 展开 constructor 查看具体实例 → 点击实例 → 右侧 “Retainers” 标签页，看谁在引用它（这是定位根源的关键）
常见泄漏模式与快照特征
不是所有增长都算泄漏，但以下模式在快照中非常典型：
立即学习“Java免费学习笔记（深入）”；
- DOM 节点残留：明明已 remove()，但快照里仍有 detached HTMLDivElement，Retainers 显示被闭包或事件监听器持有
- 定时器未清除：setTimeout/setInterval 回调闭包中引用了外部大对象（如整个 Vue 组件实例），导致组件无法 GC
- 事件监听器未解绑：addEventListener 添加了，但 removeEventListener 用错函数引用（比如传了匿名函数或箭头函数）
- Map/Set 缓存无限增长：键为对象或函数，又没做失效清理，快照中看到大量 MapEntry 持有旧对象
配合其他工具交叉验证
快照是静态切片，需动态行为佐证：
- 开启 “Record allocation stack traces”（小齿轮 →勾选），能直接看到对象是在哪行代码 new 出来的
- 用 Performance 面板录制操作过程，查看内存曲线是否阶梯式上升
- 在 Console 中手动运行
gc()（需开启 “Developer Tools experiments” → 启用 “Disable garbage collection” 才可见），强制触发 GC 后再拍快照，排除 GC 延迟干扰
