TL;DR 速览
- 先分清三类问题：内存泄漏是对象不再使用却仍被强引用、无法回收；内存膨胀是占用高但可回收，属于数据量或设计问题；内存抖动是频繁分配与回收导致 GC 压力上升。判断错类型，后续手段就会用错方向。
- 三步排查路径：先用 Performance 录制并重复同一操作，看内存曲线是否阶梯式上升；再用三次堆快照对比（操作前、操作后、再次操作后）定位持续增长的对象类型；最后用 Allocation instrumentation on timeline 结合调用栈追踪到具体代码位置。
- 常见泄漏模式：未解绑的事件监听器与全局事件总线订阅、定时器与 requestAnimationFrame 未清理、闭包意外持有大对象、游离 DOM 节点、Map/Set 缓存无上限增长、Promise 与异步任务中的悬挂引用、第三方库与框架订阅未销毁。
- 修复与验证闭环：修复引用后必须用同一套可复现操作脚本复测，确认内存曲线回归平稳，并补充回归测试与线上监控，避免问题复发。
- 工程化预防：通过性能预算、CI 中的内存基线检查、代码评审清单与线上真实用户监控（RUM）形成长期防护，把内存问题挡在发布之前。
目录
- 一、引言：为什么 Chrome 内存泄漏值得认真对待
- 二、先分清概念：内存泄漏、内存膨胀与内存抖动
- 三、诊断前的准备：工具与观测基线
- 四、第一步：用 Performance 录制确认泄漏是否存在
- 五、第二步：堆快照对比定位泄漏对象
- 六、第三步：分配时间线追踪泄漏来源
- 七、常见泄漏模式与对应特征
- 7.1 未解绑的事件监听器
- 7.2 定时器未清理
- 7.3 游离 DOM 节点
- 八、框架场景下的排查要点
- 九、从诊断到修复：验证闭环
- 十、工程化预防：把内存问题挡在发布之前
- 十一、总结
一、引言：为什么 Chrome 内存泄漏值得认真对待
从内存泄漏的典型表现切入，说明它对用户体验、页面稳定性和线上成本的实际影响，并给出本文的阅读目标与适用读者。
二、先分清概念：内存泄漏、内存膨胀与内存抖动
辨析三个容易混淆的概念，说明只有先判断问题类型，后续的排查手段才不会用错方向。
- 内存泄漏：不再使用的对象仍被引用，无法被回收。
- 内存膨胀：内存占用高但可回收，属于设计或数据量问题。
- 内存抖动：频繁分配与回收导致 GC 压力上升。
| 概念 | 成因 | 典型表现 | DevTools 中的识别信号 | 处理方向 |
|---|---|---|---|---|
| 内存泄漏 | 不再使用的对象仍被强引用（未解绑监听器、未清理定时器、游离 DOM、无上限缓存等） | 内存随操作次数阶梯式上升，强制 GC 后仍不回落，长时间使用后页面卡顿甚至崩溃 | Performance 内存曲线呈阶梯状；堆快照 Comparison 中 Delta 持续为正；Retainers 能追到异常持有链 | 用三次快照对比与分配时间线定位持有链，修复引用后复测曲线是否回归平稳 |
| 内存膨胀 | 数据量过大或设计不合理，一次性加载、缓存全量数据，但对象本身可被回收 | 内存水位整体偏高，操作结束后能回落，但峰值远超预期，低端设备易触发 OOM | Performance 中堆内存峰值高但曲线可回落；Summary 视图里大对象（数组、字符串、图片）占比突出 | 优化数据结构与加载策略，分页、虚拟列表、懒加载，设定内存预算并持续观测峰值 |
| 内存抖动 | 短时间内频繁创建与销毁对象，常见于循环内创建临时对象、动画帧中分配内存 | GC 频繁触发，页面出现周期性卡顿、掉帧，内存曲线呈锯齿状剧烈波动 | Performance 中 GC 事件密集；Allocation timeline 上分配条带密集且多为短命对象 | 复用对象与缓冲池，减少循环内分配，把高频分配逻辑移出渲染关键路径 |
据此选择排查路径：若内存曲线阶梯上升且强制 GC 后不回落，按内存泄漏处理，优先走堆快照对比与分配时间线；若峰值高但能回落，按内存膨胀处理，重点看数据规模与加载策略；若曲线呈锯齿状且 GC 频繁，按内存抖动处理，优先排查高频分配点。
三、诊断前的准备：工具与观测基线
介绍 Chrome DevTools 中
