chrome devtools 提供分层诊断路径：先用任务管理器确认异常，再用 performance 面板观察 js heap 和 nodes 曲线趋势，接着拍堆快照对比 retained size 与 detached dom，最后用 allocation 工具定位泄漏代码行。
页面内存占用高，不等于一定有泄漏——可能是合理使用，也可能是泄漏、膨胀或频繁 GC。关键看趋势和对象状态。Chrome DevTools 提供了一套分层诊断路径，从实时监控到深度溯源，能帮你快速区分问题类型并定位根源。
看任务管理器：先确认是否真异常
按 Shift + Esc 打开 Chrome 任务管理器，右键表头勾选 JavaScript memory 和 Memory 两列：
- Memory（原生内存）持续上涨 → 关注 DOM 节点、Canvas、WebGL 纹理等未释放资源
- JavaScript memory 括号内数值（JS 堆实时值）持续走高且 GC 后不回落 → 强烈提示内存泄漏
- 关闭标签页后内存未下降 → 渲染进程残留，大概率存在跨生命周期强引用
用 Performance 面板抓趋势
切换到 Performance 面板，勾选 Memory 和 Screenshots，录制一次典型操作（如列表滚动、弹窗打开/关闭）：
- 观察 JS Heap 曲线：若每次操作后峰值不断抬高，且 GC（下降段）无法回到初始水平，说明对象未被回收
- 同步查看 Nodes（DOM 节点数）曲线：若只增不减，尤其在组件卸载后仍维持高位，大概率存在 detached DOM
- 放大 GC 间隙：若 GC 频繁触发且间隔越来越短，说明堆压力大，可能由大量短生命周期对象或闭包持有导致
拍堆快照：定位“谁占得多、为何删不掉”
进入 Memory 面板，选择 Heap snapshot，按需拍摄多个快照（例如：空闲时、操作后、关闭模块后）：
- 对比快照，筛选 Retained Size 排名靠前的对象：小对象但 Retained Size 极大（如 VueComponent、ReactRoot、自定义 Class 实例），说明它持有了大量下游资源
- 重点看 detached DOM trees：数量达数百上千，且引用链指向已卸载的组件或闭包 → 典型 DOM 泄漏
- 展开可疑对象的 Retainers 链：逐级向上看是谁在引用它，常见源头包括全局变量、未清理的事件监听器、定时器回调、缓存 Map 中的 key
查分配源头：找到代码里哪一行在“造漏”
启用 Allocation instrumentation on timeline（内存分配时间轴），勾选 Record allocations 并开始录制：
- 操作过程中，观察哪些构造函数被高频分配（如
new Chart()、document.createElement、自定义类实例） - 点击某次分配点，DevTools 会跳转到源码中对应行 —— 这就是泄漏对象的诞生地
- 结合上下文判断：是否在事件回调、定时器、Promise 回调中创建了未被销毁的引用？是否把本该局部作用域的对象挂到了 window 或长期存活对象上？
