如何运用 Performance 面板定位 JavaScript 内存问题

Performance面板JS Heap曲线可快速判断内存问题：若操作后内存不回落、阶梯上涨或GC后残留大量对象，即存在泄漏或膨胀；配合Allocation Sampling和事件日志可定位问题代码。

直接看 Performance 面板的 JS Heap 曲线，就能判断是否存在内存问题。如果操作后内存不回落、阶梯式上涨，或 GC 后仍残留大量对象，基本就是泄漏或膨胀；配合 Allocation Sampling 和事件日志，还能快速锁定问题代码位置。

Performance 面板是观察内存动态行为的第一道关卡
它不依赖快照分析，而是用时间轴呈现真实运行中的内存变化趋势，适合快速验证“有没有问题”和“什么时候出的问题”。

• 打开 Performance 面板前，先关掉所有无关标签页和扩展（尤其是 React/Vue DevTools、广告拦截插件），避免干扰数据
• 勾选 Memory、Screenshots 和 JavaScript samples 选项，确保能捕获堆变化、帧截图和脚本调用细节
• 录制时按“操作 → 等待 3–5 秒 → 操作 → 等待”节奏执行至少 3 轮相同动作（比如打开/关闭弹窗），每轮结束后手动点垃圾桶图标触发 GC

重点盯住 JS Heap 轨道的走势形态
火焰图顶部那条蓝色曲线就是关键指标：

• 若每次操作后曲线都明显抬高、无法回落到起始 ±1MB 范围，说明对象未被回收，存在泄漏
• 若曲线反复冲高又回落，但回落后的基线逐轮上移（像爬楼梯），这是典型泄漏特征
• 若曲线持续缓慢爬升且 GC 频次变高（每 10 秒超过 5 次），可能是大量短命对象堆积，导致 GC 压力过大

结合 Summary 和 Event Log 定位线索
停止录制后，把时间轴拖到某次操作峰值处：

• 看 Summary 区域的 Nodes、Documents、Listeners 数量是否同步激增——比如点击一次按钮，Listener 增加 20 个却没减少，大概率漏了 removeEventListener
• 在 Event Log 中搜索 setTimeout、setInterval、addEventListener 等关键词，检查是否有重复注册但未清理的情况
• 若某段 JS 执行后 JS Heap 突然跳涨，再点开下方 Main 线程对应任务，双击进入 Call Tree，就能看到具体哪一行代码分配了大量对象

用 Allocation Sampling 辅助识别高频分配源
这个功能比完整堆快照轻量，适合在录制中实时观察：

• 开启录制前，在右上角齿轮里勾选 Allocation sampling
• 录制结束后切换到底部 Bottom-Up 标签，按 Allocations 列降序排列
• 找到分配次数最多、总大小最突出的构造函数（如 new Object()、Array.from、自定义类），再顺着调用栈往上查，往往就是泄漏源头

不复杂但容易忽略