直接看内存曲线、拍快照比对、查保留路径是浏览器排查内存泄漏最实在的三步法：先用任务管理器初筛静置与操作后内存是否阶梯上涨，再用Performance面板观察JS Heap GC后回落极小，最后用Memory面板拍三张快照对比Delta，通过Retaining tree定位带@符号的强引用源头。
直接看内存曲线、拍快照比对、查保留路径，是浏览器里最实在的三步法。不需要等页面卡死再动手，问题刚冒头就能抓住。
用任务管理器快速初筛泄漏迹象
Shift + Esc 打开浏览器任务管理器，盯住目标标签页的“内存”列：
- 静置 10 秒，内存应基本不动
- 反复打开/关闭同一个模块（比如弹窗或列表页）5 次，每次操作后内存若持续上涨、不回落，大概率已泄漏
- 若单次操作后内存增长超 20MB，且多次重复后阶梯式上升，基本可确认泄漏存在
用 Performance 面板抓运行时行为
打开 DevTools → Performance 面板 → 勾选 “Memory” → 开始录制 → 执行操作（滚动、点击、切换）→ 停止：
- 观察 “JS Heap” 曲线：如果每次 GC 后回落极小（比如只降 1–2MB），说明大量对象没被回收
- 曲线呈明显阶梯状上升，就是泄漏在积累的直观证据
- 可同时勾选 “Screenshots”，方便回溯对应操作节点
用 Memory 面板拍快照定位具体对象
这是真正找到“谁在拽着内存不放”的关键：
- 刷新页面 → 点击 “Collect garbage”（小垃圾箱图标）→ 再点 “Take heap snapshot” 拍第一张（基线）
- 执行可疑操作（如连续进入/退出某个页面）→ 再次 GC → 拍第二张
- 重复一次操作 → 第三次 GC → 拍第三张
- 切换到 Comparison 视图，对比第二、三张快照，重点关注：
-
# New列非零的Closure、Detached HTMLDivElement、EventListener、自定义构造函数 - 点击某行 → 右侧看 “Retaining tree”，从上往下找第一个带
@符号的对象——它就是强引用源头，通常就是泄漏代码所在位置
-
重点盯这四类典型泄漏源
80% 的问题出在这几处，排查时优先检查：
-
addEventListener绑定后没配对调用removeEventListener，尤其scroll、resize、input这类高频事件 -
setInterval/setTimeout回调里捕获了this、DOM 节点或大数组，却没在组件卸载时clearInterval(id) - DOM 节点被
remove()或innerHTML = ''清空后，JS 变量（如const el = document.getElementById('x')）仍持有引用 - 闭包返回的长期存活函数，悄悄锁住了万级数组、接口原始响应数据或整个组件实例
不复杂但容易忽略。真正的问题往往不在技术多难，而在“以为它自己会消失”的那一瞬间。
