JS排查内存飙升关键在定位突增源头，Chrome DevTools的Allocation Timeline可按毫秒记录分配调用栈与对象类型；需开启Record allocation stacks，通过蓝色尖峰识别突增区间，下钻分析高频分配类型及调用栈，并结合Heap Snapshot对比验证是否泄漏。
JS 中排查突发内存飙升，关键不是看“用了多少内存”，而是看“谁在什么时间分配了大量内存”。Chrome DevTools 的 Allocation Timeline（内存分配时间线）正是为此设计的——它能按毫秒级精度记录每次堆分配的调用栈和对象类型，帮你精准定位“突增源头”。
开启并录制 Allocation Timeline
打开 Chrome DevTools → Memory 面板 → 选择 Allocation timeline → 点击左上角录制按钮（●）→ 复现业务操作（如点击按钮、滚动、加载数据）→ 再次点击停止录制。
注意：务必在录制前勾选 Record allocation stacks（默认可能关闭），否则看不到调用栈，无法定位代码位置。
识别突增区间并下钻分析
录制结束后，时间轴会出现蓝色尖峰（代表该时间段内分配量显著升高）。鼠标悬停尖峰处可看到具体分配字节数；点击尖峰，下方会显示该时段内所有新分配对象的汇总列表（按构造函数或类型分组）。
- 优先关注 Array、Object、String、闭包（Closure）、Promise、Event Listener 等高频分配类型
- 若某类对象（如
MyDataItem或renderedNode）在尖峰中占比极高，说明它极可能是问题载体 - 点击该类型行，右侧会展示完整的调用栈（Call Stack），直接定位到 new 实例、数组创建、或闭包生成的具体代码行
结合代码逻辑验证泄漏路径
拿到可疑调用栈后，重点检查三类典型模式：
- 未清理的事件监听器：比如组件挂载时 addEventListener，但卸载时忘记 remove，导致整个作用域闭包长期驻留
- 意外保留的大数组/缓存：例如每次请求都 push 到全局数组，却无清理机制；或使用 Map/Set 缓存 DOM 节点但未随节点销毁而删除
- 频繁创建中间对象：如循环中反复 JSON.parse(JSON.stringify(obj))、或在 render 函数里新建对象/函数作为 props，触发子组件重复挂载与内存累积
对比快照确认是否真正泄漏
Allocation Timeline 显示的是“分配”，不等于“泄漏”。要确认是否持续增长，需配合 Heap Snapshot：
在突增前后分别拍两个快照 → 使用 Comparison 视图 → 查看 Objects allocated between snapshots 中数量/大小明显增加的构造函数 → 结合 Retainers（引用链）看为何没被回收。
如果某个对象在 Allocation Timeline 中高频出现，又在 Comparison 中稳定留存且有强引用链（如 window.xxx、timer 回调、未解绑的 observer），基本可断定是泄漏源。
Allocation Timeline 不是万能，但它把“内存问题”从模糊猜测变成可定位、可复现、可验证的工程问题。核心在于：录得准、看得清、查得深、验得实。
