直接看内存曲线、拍快照比对、查保留路径是浏览器排查内存泄漏最实在的三步法：先用任务管理器初筛静置与操作后内存是否阶梯上涨，再用performance面板观察js heap gc后回落极小，最后用memory面板拍三张快照对比delta，通过retaining tree定位带@符号的强引用源头。

直接看内存曲线、拍快照比对、查保留路径，是浏览器里最实在的三步法。不需要等页面卡死再动手，问题刚冒头就能抓住。

page-agent 浏览器控制（CDP）

使用 page-agent CLI（CDP）控制浏览器；CLI只能通过 GitHub Release 的 .tgz 安装，npm 官方包暂未发布。

下载

用任务管理器快速初筛泄漏迹象
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')）仍持有引用
• 闭包返回的长期存活函数，悄悄锁住了万级数组、接口原始响应数据或整个组件实例

不复杂但容易忽略。真正的问题往往不在技术多难，而在“以为它自己会消失”的那一瞬间。