内存泄漏在Allocation Instrumentation on Timeline中不直接显形，但高频未节制分配行为会以密集绿色条块形式暴露，尤其与CPU尖峰重叠时；需区分Performance面板的轻量实时追踪与Memory面板的周期快照两种模式，配合使用定位暴涨点与retain path。

内存泄漏本身不会直接在 Allocation Instrumentation on Timeline 中“显形”，但它常由高频、重复、未节制的内存分配行为驱动——而这类行为恰恰是这个工具最擅长捕捉的。你不是在找“泄漏对象”，而是在找“谁在疯狂 new、Array、Closure，且后续没被及时释放”。只要分配节奏与 CPU 尖峰同步、绿色条块持续密集堆叠，就极可能是泄漏源头的温床。

关键：区分 Allocation Instrumentation on Timeline 的两种使用场景

它有两个常见入口，但目的和机制完全不同，用错就白忙：

• Performance 面板 → ⋯ 菜单 → 勾选 Allocation instrumentation on timeline：轻量级实时追踪，只记录 new、Array、function、Closure 等构造操作的时间点 + 调用栈 + 构造函数名，开销小，适合捕获瞬时脉冲，对齐 CPU 尖峰
• Memory 面板 → 选择 Allocations on timeline 模式 → 点 Start：周期性拍堆快照（默认每 50ms），生成带持久 ID 的对象生命周期图，适合分析对象是否长期存活、是否形成 retain path

定位“暴涨点”必须用前者；后者用于验证“这些分配出来的对象后来去哪了”。两者配合，才构成闭环。

操作必须卡准节奏，否则信号会被稀释

这不是录个视频那么简单，要让分配行为和主线程压力严格对齐：

• 点击录制后，等满 1 秒再开始操作——给 V8 分配追踪器留出初始化窗口
• 复现问题时动作要集中：比如连续点击按钮 5 次、拖动滑块保持 2 秒、快速滚动列表 10 行，避免间隔过长或零散点击
• 停止录制前再等 1 秒——很多短命闭包、事件处理器会在交互结束瞬间批量生成，提前停会漏掉关键尾巴

看懂绿色 Allocations 轨道里的危险信号

录制完成后，火焰图下方出现的绿色轨道就是核心线索：

• 绿色条块越密集、越连续，说明该时间段内分配越频繁；若恰好叠在 CPU 占用尖峰上，基本可断定是同一根源
• 点击任意绿色条块，在右侧 Call Tree 中重点看顶部函数——它是触发本次分配的直接调用者，不是深层嵌套的工具函数
• 构造函数名显示为 Closure，代表这是一个闭包实例；若反复出现 Closure + 同一父函数名（如 render、handleScroll、onInput），就是高频闭包创建的铁证
• 看到 Array、Object、RegExp 高频出现，且调用栈指向某次循环或重复渲染逻辑，立刻检查是否在循环里写了 []、{} 或 new RegExp()

高频分配背后的真实风险不只是内存增长

表面看是内存涨了，实际会连锁引发两个隐藏性能黑洞：

• V8 每次新建闭包都要分配堆内存 + 构建作用域链，这部分开销在火焰图里不单独显示，但会显著拉高父函数执行耗时
• 这些对象生命周期极短，很快进入待回收队列，迫使 GC 频繁触发——你会在 Performance 面板 Memory 轨道中看到密集的 GC 小锯齿，这是泄漏正在发生的间接证据
• 如果某次操作后，绿色分配条消失，但内存曲线没回落，说明对象被意外保留（比如挂到了全局变量、事件监听器未解绑、闭包捕获了大数组），这时切换到 Memory 面板 → Allocations on timeline 模式重录，对比快照就能确认 retain path