精通JavaScript内存泄漏排查需建立“对象生命周期—引用链—GC判断”直觉，紧盯Closure、Timer、Global、Detached四类强引用链，善用Allocation Timeline实时监控，编码时主动断链，并将无泄漏纳入接口契约。
精通 JavaScript 内存泄漏排查，不靠死记硬背，而在于建立“对象生命周期—引用链—GC 判断”三位一体的直觉。真正上手快、定位准、修复稳的人，往往只做三件事：盯住引用链源头、卡准 GC 触发时机、用工具反推代码行为。下面这些是经过多个大型 SPA 和后台系统验证过的实战要点。
盯住四类强引用链，它们是泄漏的“主干道”
所有泄漏本质都是“不该活的对象被某条路径拽着”。Chrome DevTools 的 Retainers 面板里，90% 的泄漏对象引用链最终都会落到以下四类节点上：
- Closure：闭包本身不是问题，但若它长期存活（比如绑定在全局事件或定时器上），且捕获了大数组、DOM 节点或组件实例，就会把整条作用域链钉在堆里；
- Timer：setInterval 的回调函数只要没 clear，它的执行上下文就一直挂在全局任务队列中，闭包内所有变量都无法释放；
-
Global：包括 window 上未声明变量（
a = []）、显式挂载（window.cache = bigObj）、或模块顶层意外导出的大对象； - Detached：已从 DOM 树移除但 JS 仍持有引用的节点——这类对象常连带整个子树（含样式、事件监听器、布局信息）滞留内存，Retained Size 往往异常高。
用好 Allocation Timeline，比堆快照更早发现苗头
堆快照适合“事后验尸”，而 Allocation Timeline 是“实时监控心电图”。开启它后（Memory → Allocation instrumentation on timeline），反复触发疑似泄漏操作（如打开/关闭弹窗），观察蓝色小方块（新分配对象）是否持续出现在同一构造器下，且不随操作结束而消失：
- 如果
Array或Object构造器下方出现一长串连续分配，说明有循环创建未销毁的结构； - 如果
HTMLDivElement分配后长期不回收，大概率是 DOM 引用未解绑； - 点击某段蓝色区域，右键 “Reveal in heap snapshot”，可直接跳转到对应对象，查它被谁 retain。
写代码时主动“断链”，而不是等 GC 救你
GC 不会帮你猜意图。很多开发者以为“函数退出就自动清理”，但闭包、事件监听、定时器会绕过这个逻辑。关键动作是“显式切断”：
- 组件卸载时，把闭包持有的 DOM 变量设为
null，不只是移除监听器； - 定时器回调里避免直接引用 this 或大型数据，改用 ID + 查询模式（
document.getElementById(id)）； - 缓存逻辑不用
window.xxx，改用WeakMap存 DOM → 数据映射，DOM 被删，引用自动失效； - 启用严格模式（
'use strict';），让漏声明变量直接报错，从源头掐掉全局泄漏。
把泄漏当接口契约来设计
高级团队会把“无泄漏”写进组件 API 合约。例如 React 自定义 Hook 必须返回 cleanup 函数；Vue 组件必须在 beforeUnmount 中清空所有 timer/setTimeout；自研 SDK 初始化后必须提供 .destroy() 方法，并明确文档其释放范围（是否包括内部监听、缓存、WebSocket）。这不是过度设计，而是把内存责任前移到开发阶段，避免后期堆快照里翻几十层引用链。
