javascript内存泄漏排查需三步：先用chrome任务管理器、performance面板验证内存持续增长；再通过memory面板拍快照对比，定位delta为正的可疑对象；最后在retainers中追溯window、setinterval等“拽住者”并修复验证。
JavaScript 内存泄漏排查不是靠经验猜测，而是用 Chrome DevTools 捕获真实内存行为，再结合引用关系锁定代码源头。核心动作就三步：确认增长、定位对象、追溯谁在持有它。
先看内存有没有真在涨
别急着开堆快照，先做快速验证：
- 打开 Chrome 任务管理器（Shift + Esc），找到你的页面标签，盯着“内存”列——静置 10 秒还在爬升，或操作后不回落，就是异常信号
- 重复执行同一操作（比如打开/关闭弹窗）10 次，每次操作后内存比前一次高 10% 以上，说明对象没释放
- 进 Performance 面板，勾选 “Memory”，录制 10 秒。如果 JS Heap 曲线呈阶梯式上升、GC 标记频繁但回收后内存不降，基本可判定泄漏存在
拍快照对比，揪出新增对象
确认有问题后，进入 Memory 面板深度分析：
- 点击 Collect garbage（小垃圾箱图标），强制触发一次 GC，清掉干扰项
- 点击 Take heap snapshot，拍下初始快照（命名为“基线”）
- 执行疑似泄漏的操作（如打开模块 → 关闭 → 再打开），重复 2～3 轮，每轮后都点一次 GC + 拍快照
- 选中最新快照，切换到 Comparison 视图，与基线快照对比
- 重点关注 Delta 列为正且持续增长 的类型：比如
(closure)、HTMLDivElement、EventListener、Detached DOM tree、自定义类名
顺着引用链，找到代码里的“拽住者”
发现可疑对象后，关键是查清楚谁在阻止它被回收：
- 双击某个增长明显的构造函数（如某 Closure 或 Detached 节点），右侧自动展开 Retainers 面板
- 勾选底部 Show all retainers，确保看到完整引用路径
- 重点识别这些“拽住者”：window（全局变量）、setInterval（未清除的定时器）、EventListener（没 remove 的监听器）、detached HTMLButtonElement（已移除但 JS 还拿着的 DOM）
- 点击引用链中的文件链接，直接跳转到 Sources 面板 对应代码行，定位问题源
验证修复是否真正生效
改完代码不能只看“好像不卡了”，要闭环验证：
- 重新走一遍快照流程：修复后，对应 Closure 数量应下降或归零，Detached DOM 不再增长
- 再次用 Performance 面板录制 10 秒，JS Heap 曲线应回落平缓，GC 后内存明显下降
- 检查 Retainers 中原来出现的 timer、detached 元素、全局缓存变量，是否已从该对象的引用链中消失
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
