allocation instrumentation on timeline 是用于实时定位内存分配热点的工具，仅记录new、function、array等操作的时间点、调用栈和构造函数名，开销小、响应快，适合捕获瞬时内存脉冲。

Allocation Instrumentation on Timeline 不是用来“事后分析”的工具，而是能在 CPU 峰值发生的同时，直接标出哪行代码正在高频分配内存。它不记录对象内容，只抓取 new、function、Array 等关键操作的**时间点 + 调用栈 + 构造函数名**，因此开销极小、响应及时，特别适合定位“一闪而过”的内存脉冲。

开启前必须确认的三件事

这个功能容易被误开在错误位置，导致录制无效：

• 必须在 Performance 面板中操作，不是 Memory 面板 —— 后者同名选项仅用于采样式内存分析，无法对齐时间线
• 勾选路径是：Performance 面板右上角 ⋯ → 勾选 Allocation instrumentation on timeline
• 录制前务必清空已打开的其他 DevTools 面板（如 Console 或 Network 的长时日志），避免干扰主线程调度和时间精度

录制时的操作要点

不是“随便点几下”，而是要让分配行为与 CPU 尖峰严格同步：

• 点击录制按钮后，等 1 秒再开始交互 —— 给 V8 分配追踪器留出初始化窗口
• 复现问题操作时，动作要集中、有节奏：比如连续快速点击某个按钮 5 次，或拖动滑块持续 2 秒，避免零散操作稀释信号
• 停止录制前，再等 1 秒 —— 确保最后一批分配事件被完整捕获，尤其闭包类短命对象常在交互结束瞬间批量生成

看懂绿色 Allocations 轨道的关键信号

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

• 绿色条块越密集、越连续，说明该时间段内分配越频繁；若恰好叠在 CPU 占用尖峰区域上，基本可断定是同一根源
• 点击任意绿色条块，在右侧 Call Tree 中重点看顶部函数 —— 它是触发本次分配的直接调用者
• 构造函数名显示为 Closure，代表这是一个闭包实例，不是普通对象；反复出现 Closure + 同一父函数名（如 render、handleScroll），就是高频闭包创建的铁证
• 若看到 Array、Object、RegExp 等构造函数高频出现，且调用栈指向某次循环或重复渲染逻辑，也需立即检查是否在不该新建的地方写了字面量或构造调用

高频分配背后的真实风险

表面是内存增长，实际会连锁引发两个性能黑洞：

• V8 每次新建闭包都要分配堆内存 + 构建作用域链，这部分开销在火焰图里不会单独显示，但会显著拉高父函数的执行耗时
• 这些闭包生命周期极短，很快进入待回收队列，迫使 GC 频繁触发 minor GC，表现为 Timeline 上规律性出现的“JS Heap 下降尖刺”+ CPU 短时飙升
• React/Vue 场景中，onClick={() => doX()} 这类写法每渲染一次就新建一个闭包，哪怕组件没更新，只要 props 变化触发重渲染，分配就会重复发生