当你发现页面越用越卡，内存占用只升不降，大概率就是 Ja vaScript 内存泄漏了。别慌，我们有条理可循。

存在 Ja vaScript 内存泄漏时，可按以下步骤排查：

• 先用 Chrome 任务管理器初筛
• 再通过 Performance 面板观察 JS Heap 曲线是否不回落
• 接着用 Memory 面板执行“GC + 三快照 + 对比”，定位增长对象
• 最后用 getEventListeners 和 querySelectorAll 命令，直查监听器与 DOM 节点泄漏

测试页面时，如果操作几次后页面变卡、内存持续上涨且不回落，说明可能存在 Ja vaScript 内存泄漏。必须快速定位到具体代码位置，才能推进修复。

用浏览器任务管理器做 30 秒初筛

按 Shift+Esc 直接唤出 Chrome 任务管理器。找到对应网页进程，观察“内存”列数值。

静置 10 秒后，若内存仍缓慢爬升（如每 30 秒涨超 50MB），或重复执行同一操作（如打开/关闭弹窗）10 次后内存阶梯式上涨，就基本可判定存在泄漏。

这一步跳过 DevTools，直接看系统级指标，可避免被快照延迟或 GC 干扰误判。

Performance 面板抓取动态泄漏证据

这是定位“只增不减”型泄漏最直观的方法，能锁定泄漏发生的具体时间点和行为。

第一步：打开开发者工具 → 切换到 Performance 面板 → 勾选 Memory 和 Screenshots → 点击录制按钮 ●

第二步：执行一次疑似泄漏的操作（例如点击“加载更多”按钮 5 次）→ 操作结束立即点停止 ■

第三步：在火焰图下方的内存曲线中，找到蓝色 JS Heap 线。如果操作结束后线条未回落甚至继续上扬，说明对象未被回收。把鼠标悬停在线条峰值处，下方 Summary 区域会显示该时刻新增的 DOM 节点数、监听器数等关键指标。

注意：若 Memory 未勾选，整条曲线将不显示，无法判断 JS 堆变化。

Memory 面板拍快照比对增长对象

快照对比是定位泄漏源头的核心手段。但必须严格遵循“先 GC 再拍照”流程，否则数据全是噪音。

方法一：基础三快照法

• ① 打开 Memory 面板 → 点击垃圾桶图标 Collect garbage → 点击 Take heap snapshot，命名为 “Snapshot 1”
• ② 执行一次完整业务操作（如进入列表页→点击某项→返回）→ 再次点击垃圾桶 → 拍摄 “Snapshot 2”
• ③ 重复步骤②一次 → 拍摄 “Snapshot 3”

方法二：精准对比模式

在 Snapshot 3 的左上角下拉菜单中选择 Comparison → 顶部切换为 Objects allocated between snapshots 2 and 3。展开后重点查看以下几类构造函数的新增数量：

• (closure)
• EventListener
• HTMLDivElement
• Detached DOM tree

若某类对象持续增长（如 closure 多出 200+ 个），右键它 → 选择 Reveal in Summary view → 查看右侧 Retainers 树，就能看到是哪个模块、哪行代码强引用了它。

【关键前提】 每次拍照前必须手动点垃圾桶触发 GC，否则快照里塞满本该回收的对象，对比完全失真。

控制台命令直查高危泄漏点

80% 的内存泄漏来自事件监听器残留和脱离 DOM 节点。这两条命令能绕过快照分析，3 秒内给出线索。

命令一：输入 getEventListeners(document) 回车，查看全局监听器总数。反复执行组件切换操作后再次运行，若监听器列表明显变长（尤其出现重复绑定的 scroll、resize），说明未调用 removeEventListener。

命令二：输入 console.dir(document.querySelectorAll('*').length) 获取当前 DOM 节点总数。再执行可能造成节点堆积的操作（如无限加载），若节点数暴涨且不回落，配合 Elements 面板搜索 detached，可快速定位残留节点。

《夸克》非常好用的免费AI浏览器

下载APP查看