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 能追到异常持有链用三次快照对比与分配时间线定位持有链，修复引用后复测曲线是否回归平稳内存膨胀数据量过大或设计不合理，一次性加载、缓存全量数据，但对象本身可被回收内存水位整体偏高，操作结束后能回落，但峰值远超预期，低端设备易触发 OOMPerformance 中堆内存峰值高但曲线可回落；Summary 视图里大对象（数组、字符串、图片）占比突出优化数据结构与加载策略，分页、虚拟列表、懒加载，设定内存预算并持续观测峰值内存抖动短时间内频繁创建与销毁对象，常见于循环内创建临时对象、动画帧中分配内存GC 频繁触发，页面出现周期性卡顿、掉帧，内存曲线呈锯齿状剧烈波动Performance 中 GC 事件密集；Allocation timeline 上分配条带密集且多为短命对象复用对象与缓冲池，减少循环内分配，把高频分配逻辑移出渲染关键路径据此选择排查路径：若内存曲线阶梯上升且强制 GC 后不回落，按内存泄漏处理，优先走堆快照对比与分配时间线；若峰值高但能回落，按内存膨胀处理，重点看数据规模与加载策略；若曲线呈锯齿状且 GC 频繁，按内存抖动处理，优先排查高频分配点。三、诊断前的准备：工具与观测基线介绍 Chrome DevTools 中