allocation timeline可毫秒级追踪堆分配，需开启record allocation stacks；尖峰处聚焦array、object等高频类型及自定义类调用栈；结合heap snapshot比对确认是否泄漏。
分析堆内存分配时间线，核心是抓住“谁在什么时间大量分配了什么对象”，而不是只看总内存用了多少。Chrome DevTools 的 Allocation Timeline（分配时间线）专为此设计，能以毫秒级精度记录每次堆分配的调用栈和类型。
开启录制并确保调用栈可用
打开 Memory 面板 → 选择 Allocation timeline → 录制前务必勾选 Record allocation stacks（默认常关闭）。不勾这项，后续看到尖峰也找不到代码位置。
点击 ● 开始录制 → 在页面上复现疑似问题的操作（如连续打开/关闭弹窗、滚动加载列表、触发搜索等）→ 再次点击停止。
识别突增区间并聚焦高频分配类型
录制结束后，时间轴上出现的蓝色尖峰代表该时段分配量激增。鼠标悬停可查看具体字节数；点击尖峰，下方会列出该时段内所有新分配对象的汇总，按构造函数或类型分组。
- 优先关注 Array、Object、String、Closure、Promise、EventListener 等高频类型
- 若某自定义类（如
UserInfoCard或renderedNode）在尖峰中占比突出，它大概率就是泄漏载体 - 点击该类型行，右侧显示完整调用栈，直接定位到
new、push、addEventListener等具体语句
结合常见泄漏模式验证代码逻辑
拿到可疑调用栈后，重点检查三类典型场景：
-
事件监听器未解绑：组件挂载时绑定，卸载时没调用
removeEventListener，尤其注意匿名函数导致无法移除 -
缓存或数组持续累积：全局数组反复
push、Map/Set 缓存 DOM 节点但未随节点销毁而清理 -
渲染中频繁创建中间对象：比如
render函数里写{...props}展开、() => handler内联函数、或滥用JSON.parse(JSON.stringify())
用堆快照确认是否真正泄漏
Allocation Timeline 只反映“分配”，不等于“泄漏”。要验证是否残留，需配合 Heap Snapshot：
- 在尖峰前后各拍一次快照（操作前拍 baseline，尖峰后立即拍 second）
- 选 second 快照 → Comparison → 选 baseline 为对比基准
- 按 # New 或 Size Delta 排序，找数量/大小明显增长的构造函数
- 点开实例 → 查看 Retaining Tree，确认它是否被
window、定时器、闭包等强引用链长期持有
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
