JS Heap曲线呈“阶梯式上升”是内存泄漏最直观信号；需勾选Memory、等页面空闲、操作有明确起止点；疑似泄漏表现为每次操作后最低点持续抬升，3次以上阶梯+终点内存超起点20%+Nodes/Listeners同步涨即强泄漏；gc()无回落可确认泄漏；结合Call Tree中setInterval、addEventListener等定位闭包或事件监听器泄漏源。
直接看 JS Heap 曲线是否呈现“阶梯式上升”——这是 Performance 面板里最直观、最可靠的内存泄漏信号，比单看内存数值高得多更关键。
开启录制前必须做三件事
确保 Memory 数据真实有效，避免误判：
- 勾选 Performance 面板左上角的 Memory 复选框（不勾则整段录制无内存数据）
- 等页面完全空闲再开始：网络请求收尾、动画帧停稳、定时器无密集触发
- 操作要有明确起止点，比如“打开弹窗 → 等渲染完成 → 关闭弹窗 → 等销毁完成”，中间不打断
看曲线，重点盯三个特征
停止录制后，时间轴下方会出现 JS Heap（蓝色）、Nodes（绿色）、Listeners（橙色）三条线。只看 JS Heap 就够判断初步嫌疑：
dmap-jsapi-skill
下载
DMap GL地图JSAPI（dmapgl）开发指南。用于编写、审查、调试 DMap 地图 API 代码，涵盖地图初始化、覆盖物渲染、图层管理、事件处理、控件交互等任务。当用户提及 dmap、dmapgl、jsapi‑gl 或相关地图开发需求时自动触发。
- 正常情况：锯齿状波动，每次操作后明显回落，回落低点基本稳定
- 疑似泄漏：每执行一次相同操作，JS Heap 的最低点都比上一次高，形成一级级向上的台阶
- 强泄漏信号：阶梯连续出现 3 次以上 + 结束时内存比起点高 20% 以上 + Nodes 或 Listeners 同步上涨
用 gc() 验证是不是真卡住了
录制结束别急着下结论。切到 Console 面板，输入 gc() 并回车（需提前在 DevTools 设置 → Experiments 中启用 “Enable advanced heap snapshot features”）：
- 如果 JS Heap 几乎没变化，说明对象被强引用锁住，泄漏基本坐实
- 如果明显回落，说明只是回收延迟或缓存堆积，未必是泄漏
结合时间点定位问题函数
把鼠标悬停在某段明显上升的 JS Heap 区域上，下方会显示该时段摘要。点击它，再切到底部 Call Tree 或 Bottom-Up 标签：
- 按 Self Time 排序，找耗时异常高的函数（尤其是反复出现的）
- 展开调用链，重点关注含
setInterval、addEventListener、new Array、document.createElement的节点 - 特别留意标有
(closure)或EventListener的条目，它们常是引用未断的源头
