SPA 内存只涨不降Chrome DevTools Memory 面板实战排查一、从「跑一晚上就崩」到 Detached DOMSPA 内存泄漏的典型现场去年排查一个数据看板 SPA。运维反馈某用户的浏览器标签页跑了一晚上内存从 80MB 涨到 1.2GB最后被系统杀进程。复现路径很稳定反复切换路由加频繁打开关闭抽屉组件半小时内存能涨 200MB。这事我见过太多团队栽进去——以为是后端接口返回数据太大结果是前端自己没清理。SPA 不像传统多页应用有天然的全量回收机制。页面不刷新JS 堆里的对象就不会被整体回收。只要存在一条引用链让 GC 无法触及对象就会常驻堆中。运行时间越长泄漏累积越严重最终触发 OOM 崩溃。常见泄漏源有四类。第一未清除的setInterval/setTimeout持有回调与闭包。第二事件监听器未解绑尤其挂在window或全局 EventEmitter 上。第三闭包意外持有大对象例如缓存 Map 只进不出。第四Detached DOM——节点从文档移除但仍被 JS 引用形成「DOM 已删、引用还在」的僵尸状态。排查这类问题不能靠猜。Chrome DevTools 的 Memory 面板提供三件利器Heap Snapshot 看堆内对象分布、Allocation Timeline 看分配时段、Comparison 对比两次快照的增量。三者配合能精准定位泄漏源。二、GC 可达性与 Detached DOM内存泄漏的底层机制V8 的 GC 基于可达性分析。从一组 GC Root全局对象、活动栈、活动 DOM 树出发遍历所有可达对象不可达的标记为可回收。只要存在一条从 Root 到对象的引用链对象就不会被回收。四种泄漏源对应四种引用链模式。定时器回调持有外部变量定时器本身被全局任务队列引用形成 Root 到定时器到闭包到大对象的链。监听器挂在全局对象上回调持有组件实例组件销毁但监听器未解绑形成 Root 到全局到监听器到组件的链。闭包缓存只增不删形成 Root 到模块到 Map 到历史数据的链。Detached DOM 则是 Root 到 JS 变量到已移除 DOM 节点到其子树的链。排查流程遵循「快照对比、定位增量、追溯引用链」。先在稳定态拍基准快照操作若干次后再拍快照对比增量对象。若某类对象数量只增不减即为可疑。再用 Retainers 面板追溯引用链找到持有它的 GC Root 路径。综上泄漏排查遵循「快照对比、定位增量、追溯引用链」三步先拍基准快照再对比增量对象最后用 Retainers 追溯 GC Root 路径把盲目查找变成按步骤取证。三、生产级泄漏检测装饰器与修复模式下面给出一个可复用的泄漏检测装饰器用于自动追踪组件挂载的全局监听器与定时器并在卸载时校验是否清理干净。同时给出四类常见泄漏的修复模式。// 泄漏检测装饰器在开发环境自动校验资源清理 // 生产环境直接返回原类避免影响性能 export function trackLeaksT extends { new (...args: any[]): any }(Base: T) { if (process.env.NODE_ENV production) return Base; return class extends Base { private _timers: Setnumber new Set(); private _listeners: Array[EventTarget, string, EventListenerOrEventListenerObject] []; // 包装 setInterval记录 id 便于卸载时统一清理 trackedSetInterval(fn: TimerHandler, ms: number): number { const id window.setInterval(fn, ms); this._timers.add(id); return id; } // 包装 addEventListener记录目标与类型解绑时必须用同一引用 trackedAddEventListener(target: EventTarget, type: string, listener: EventListenerOrEventListenerObject) { target.addEventListener(type, listener); this._listeners.push([target, type, listener]); } // 统一清理在组件卸载钩子中调用漏清任一项都会在下次快照中暴露 cleanup() { for (const id of this._timers) clearInterval(id); this._timers.clear(); for (const [target, type, listener] of this._listeners) { // 必须传同一引用否则解绑失败监听器残留 target.removeEventListener(type, listener); } this._listeners []; } }; } // 修复模式一定时器必须在卸载时清除 // 错误setInterval 回调持有组件 state组件销毁后定时器仍跑 useEffect(() { const id setInterval(() tick(), 1000); return () clearInterval(id); // 清理函数是唯一兜底 }, []); // 修复模式二监听器解绑必须用同一引用 // 错误卸载时新建匿名函数解绑引用不匹配监听器残留 const handler (e: Event) update(e); window.addEventListener(resize, handler); window.removeEventListener(resize, handler); // 同一引用才能解绑 // 修复模式三缓存 Map 必须有淘汰策略 // 错误只 set 不 delete长运行下 Map 无限增长 const cache new Mapstring, any(); function setCache(key: string, value: any) { cache.set(key, value); if (cache.size 1000) { // 删除最早的键LRU 思路简化版避免无上限累积 const firstKey cache.keys().next().value; cache.delete(firstKey); } } // 修复模式四DOM 引用及时置空避免 Detached DOM // 错误组件卸载后仍持有节点引用节点无法回收 let nodeRef: HTMLElement | null document.createElement(div); document.body.appendChild(nodeRef); // 用完后显式断开引用切断 Root 到 DOM 的引用链 document.body.removeChild(nodeRef); nodeRef null;关键点在于三处。其一装饰器只开发环境生效生产环境零开销。其二监听器解绑必须传同一引用匿名函数解绑无效。其三DOM 节点移除后变量必须显式置空否则形成 Detached DOM。某运维看板接入这套检测后8 小时压测内存从 1.2GB 降到 140MB泄漏类工单清零。四、排查的代价快照开销、误报与适用边界内存排查也有副作用。第一道代价是快照开销。Heap Snapshot 会暂停主线程数百毫秒到数秒生产环境不可用只能在本地复现。Allocation Timeline 虽轻量但开启后仍有 10% 到 20% 的性能损耗影响真实交互时序。第二道代价是误报。V8 的 GC 时机不确定快照中看到的「未回收」可能是 GC 尚未触发而非真实泄漏。建议操作后等几秒再拍快照或手动点击 Memory 面板的「Collect garbage」按钮强制 GC 后再对比。第三道代价是排查成本高。复杂引用链可能跨越多个模块Retainers 面板显示的距离可能很长。对历史遗留代码定位成本远高于修复成本需评估 ROI。适用边界长运行 SPA后台系统、数据看板、在线编辑器收益最高。短生命周期页面营销活动页、一次性表单泄漏影响有限过度排查得不偿失。五、总结前端内存泄漏排查是 SPA 长运行稳定性的关键工程。落地建议第一用 Heap Snapshot 对比法定位只增不减的对象配合 Retainers 追溯引用链。第二开发环境接入泄漏检测装饰器自动追踪定时器与监听器。第三四类常见泄漏按固定模式修复定时器必清、监听器同引用解绑、缓存设淘汰、DOM 引用置空。第四快照对比前手动触发 GC避免 GC 时机误判。最终在排查成本与运行稳定性之间取得平衡。这条路在长运行 SPA 下能跑通回报是值得的。