Performance面板监控内存泄漏的核心是识别JS Heap的“阶梯式上升”曲线，即每次操作后最低点持续抬高，表明GC未清理干净；需勾选Memory录制完整操作周期，结合gc()强制回收验证强引用是否存在。
用 Performance 面板监控内存波动，核心是看 JS Heap 曲线是否出现“阶梯式上升”——这比单纯数值高更关键，它说明垃圾回收（GC）没能把操作产生的对象清干净。
开启内存录制并规范操作流程
打开 DevTools → 切到 Performance 面板 → 勾选 Memory 复选框（不勾则无内存数据）→ 点击左上角圆形录制按钮 → 执行你怀疑泄漏的操作（如打开/关闭弹窗、切换路由、滚动加载列表）→ 点击停止。
- 录制前等页面完全空闲：确保无 pending 请求、无动画帧运行、无定时器密集触发
- 操作要有明确起止：比如“打开弹窗 → 等渲染完成 → 关闭弹窗 → 等销毁完成”，避免中途打断
- 建议录制时长覆盖完整生命周期：至少包含一次操作 + 5–10 秒静默期，观察 GC 是否自然回落
识别三类典型异常曲线
录制完成后，时间轴下方会出现 JS Heap（蓝色）、Nodes（绿色）、Listeners（橙色）等曲线。重点盯 JS Heap：
- 正常波动：锯齿状起伏，每次上升后明显回落，回落低点基本稳定
- 疑似泄漏：每执行一次操作，JS Heap 最低点都比上一次高，形成阶梯
- 强泄漏信号：阶梯持续 3 次以上 + 结束时内存比起点高 20% 以上 + Nodes/Listeners 同步上涨
定位泄漏发生的时间段与函数
将鼠标悬停在 JS Heap 明显上升的某一段上，下方详情区会显示该时段摘要。点击该片段，再切到底部 Call Tree 或 Bottom-Up 标签：
立即学习“Java免费学习笔记（深入）”；
- 按 Self Time 排序，找耗时异常高的函数（尤其是重复出现的）
- 展开调用链，关注含
setInterval、addEventListener、new Array、document.createElement的节点 - 留意标有
(closure)或EventListener的条目，它们常是引用未断的源头
用 gc() 强制验证强引用是否存在
录制结束后，别急着下结论。切换到 Console 面板，输入 gc() 并回车（需提前在 DevTools 设置 → Experiments 中启用 “Enable advanced heap snapshot features”）：
- 如果 JS Heap 在
gc()后几乎没变化，说明存在强引用，泄漏基本确认 - 如果明显回落，说明对象本可回收，需检查是否只是缓存策略或操作节奏导致暂时堆积
- 配合 Memory 面板拍快照再对比，能进一步锁定具体构造函数和 Retainers 链
