allocation instrumentation on timeline 是 chrome devtools 中轻量级内存分配追踪机制，仅记录 new、函数定义、array 创建等操作的时间点、调用栈和构造函数名，不捕获对象内容；开启需在 performance 面板录制前勾选该选项，录制后通过绿色 allocations 轨道定位高频分配源，尤其擅长识别 closure 闭包引发的 cpu 峰值与内存脉冲。
什么是 Allocation instrumentation on timeline？
这是 Chrome DevTools 中一个常被忽略的内存分析开关，不是“内存快照”，也不是“性能录制”，而是一种轻量级、持续开启的分配追踪机制。它不捕获对象内容，只记录每次 new、function 定义、Array 创建等操作发生的**时间点、调用栈和构造函数名**。当你遇到 CPU 使用率突然飙升（比如 80% → 95% 持续数秒），且 Performance 面板里看到大量短生命周期函数反复执行时，这个功能比堆快照更早、更准地指向问题源头。
如何开启并正确解读 Allocation 数据
打开 DevTools → 切换到 Performance 面板 → 点击右上角 ⋯ → 勾选 Allocation instrumentation on timeline（注意：不是勾选 “Memory” 面板里的同名选项）→ 开始录制 → 复现 CPU 峰值操作 → 停止录制。
录制结束后，在底部火焰图下方会出现一条绿色的 Allocations 轨道。关键看三点：
- 绿色条块密集出现的位置，一定对应 CPU 占用尖峰区域
- 点击任意一个绿色条块，右侧
Bottom-Up或Call Tree标签页中会显示该次分配的完整调用栈，顶部是触发分配的函数 - 重点关注构造函数名为
Closure的条目——它们不是普通对象，而是闭包实例，往往意味着某个函数被反复定义或引用未释放
例如，你在 render 函数里写了 const handler = () => {...}，每次渲染都会新建一个闭包，Allocation 轨道就会在 render 调用栈下持续打出 Closure 条块，而 Performance 面板里也能看到 render 占用大量 CPU 时间。
为什么 Closure 分配容易引发 CPU 峰值？
闭包本身不慢，但高频创建闭包会同时触发两件事：V8 必须为每个新闭包分配堆内存 + 构建作用域链；垃圾回收器（GC）随后要频繁扫描这些短命闭包是否可回收。两者叠加，就会在 Timeline 上表现为 CPU 尖峰+内存小幅脉冲。
常见高危模式包括：
- 在 React/Vue 组件 render 中直接定义内联函数：
onClick={() => doSomething(id)} - 在循环中动态生成监听器：
els.forEach(el => el.addEventListener('click', () => {...})) - 使用
setTimeout或requestAnimationFrame时，每次回调都重新声明函数体 - 模块顶层导出一个工厂函数，但内部返回的闭包意外捕获了大对象（如整个 DOM 树或大型数组）
这些场景下，Allocation instrumentation on timeline 会清晰标出“谁在造闭包”，而不是等泄漏发生后才在 Memory 面板里翻 Retainers。
容易踩的坑：数据不显示 or 显示不准
这个功能默认关闭，且有隐性限制：
- 必须在录制开始前就勾选，中途开启无效
- 仅对 JS 堆分配生效，不追踪 TypedArray、WebAssembly 内存或 DOM 节点
- 如果页面开启了
Disable cache，某些懒加载模块的闭包可能延迟出现，导致分配时间点偏移 - 在 Web Worker 或 Service Worker 中无法启用——它只作用于当前渲染进程的主线程
- Chrome 124+ 版本中，若启用了
Async stack traces实验功能，闭包调用栈会更完整；否则可能只显示到co或Promise.then这一级
最常被忽略的一点：它不会告诉你“这个闭包为什么没被回收”，只告诉你“它被造出来了”。要判断是否泄漏，得结合 Memory 面板的快照对比；但要定位 CPU 峰值源头，它已经足够直接。
