如何看待通过垃圾回收监控精确定位大型SPA应用的内存增长曲线

大型SPA的内存泄漏可通过垃圾回收后内存是否回落来判别。本文将从Performance面板、Allocation追踪和堆快照等方面，详细讲解如何定位未销毁对象及常见泄漏源。

内存曲线是否呈现“该降不降”的态势，是判断大型SPA是否存在内存泄漏的直接依据。不应过分关注总内存大小，而应观察垃圾回收（GC）发生后内存的回落情况。若每次GC后释放的内存逐渐减少，甚至几乎不变，则极有可能存在被意外持有的对象，导致无法释放。

打开 Chrome DevTools 的 Performance 面板做录制

1. 横轴代表时间，纵轴表示JS堆内存（JS Heap）使用量，蓝色实线即为实时内存占用曲线。
2. 灰色竖线指示一次垃圾回收事件，对应位置应观察到明显的内存下降。
3. 若曲线呈单调上升趋势，且灰色竖线处回落幅度逐渐缩小（例如从下降30MB缩减到仅下降5MB），表明可回收对象减少，泄漏正在累积。

结合 Allocation instrumentation on timeline 捕获分配源头

1. 播放录制结果时，将鼠标悬停在内存上升段，下方会显示“Allocations”子轨道。
2. 点开某一段高亮区域，右侧Summary标签页列出新增对象最多的构造函数（如VueComponent、ReactElement、闭包函数名）。
3. 重点关注那些在用户离开页面后仍持续出现的构造函数——它们很可能没被销毁，比如未解绑的全局事件监听器、未清除的定时器、或组件内保留的DOM引用。

用 Memory 面板拍快照对比对象留存情况

1. 切换到Memory面板，选择“Heap snapshot”，点击Capture。
2. 第一张：空闲状态；第二张：操作完成后立即拍摄；第三张：离开页面并等待几秒后拍摄。
3. 用第二张减去第一张，看哪些对象数量激增；再用第三张减去第二张，看哪些对象“本该消失却还在”。
4. 特别关注Retained Size大、Distance小的对象，它们往往通过较短引用链连着GC Roots（如window、document、全局变量）。

验证常见泄漏场景是否被触发

1. 路由切换后，旧组件实例是否还挂在$refs/refs中，或被闭包捕获（如setTimeout回调里用了this）。
2. 第三方库（如地图、图表）是否调用了destroy()或remove()，而你只做了unmount却没清理底层资源。
3. 全局事件总线（如mitt、EventBus）是否在组件卸载时忘记off()，导致监听函数长期驻留。
4. 使用了WeakMap/WeakSet的地方是否误用了普通Map/Set，让对象无法被自动释放。

通过上述方法，可以系统性地排查SPA中的内存泄漏。重点检查GC后内存回落情况、堆快照对比以及常见泄漏模式，从而优化应用性能，避免累积的内存问题。