闭包本身不导致内存泄漏，但会锁死整个作用域链；真正难排查的是事件、定时器、缓存中的多层交叉引用，尤其Detached DOM被闭包捕获时会拖住整棵子树。
闭包本身不“导致”内存泄漏，但它会锁死整个作用域链——只要闭包还被某个地方持有，它能访问到的所有变量（哪怕没用上）都会被标记为“可达”，GC 就不会动它们。真正难排查的，是那些隐藏在事件、定时器、缓存结构背后的多层交叉引用。
用 Heap Snapshot 定位 Detached DOM 与闭包的交叉引用
Detached DOM 节点单独存在不会泄漏，但一旦被闭包捕获（比如作为事件回调里的 ref.current 或 document.getElementById 结果），就会通过“闭包 → DOM → 父节点链”拖住整棵子树。
- 先在组件挂载后拍一次 Heap Snapshot；
- 执行“打开→关闭→再打开”操作几次，确保 Detached 节点已生成但尚未被 GC；
- 再拍一次快照，切到 Comparison 视图，筛选 Constructor 为 HTMLDivElement（或你目标标签），勾选 Show detached elements only；
- 点开任一 Detached 节点，在右侧 Retainers 树中找带 (closure) 的条目——这就是持有它的闭包；
- 继续展开 Retainer 链，最终会落到 window、setInterval、EventListener 或某个模块级 Map 上。
检查闭包是否无意捕获了不该拿的对象
问题往往不出在“用了闭包”，而出在闭包里多抓了一个本不该长期持有的引用。比如 React 中写：
useEffect(() => {
const handler = () => console.log(ref.current);
window.addEventListener('resize', handler);
}, []);
这个 handler 闭包了 ref.current，而 ref.current 可能指向一个已被移除但未清理的 DOM 节点。
- 闭包函数是否直接访问了 this、ref.current、document.querySelector 返回值等 DOM 引用？
- 该 DOM 引用是否可能在闭包存活期间被 removeChild 或 innerHTML = '' 清空？
- 闭包是否还同时捕获了大型数据对象（如 state.dataList）？这会让 Detached DOM 和数据一起卡住。
- 避免 const el = document.querySelector('#app'); const fn = () => el.innerHTML = 'x'；改用 fn = (target) => target.innerHTML = 'x'，把 DOM 当参数传，不闭包。
揪出 setInterval / setTimeout 中的隐蔽泄漏源
定时器是最难发现的泄漏点：回调函数只要还在运行，它闭包的所有外部变量就全部保活，哪怕组件早已卸载。轮询、心跳、倒计时都容易踩坑。
- 在 Heap Snapshot 中搜索 setInterval，看其 Closure 的 Retained Size 是否异常高；
- 点开该闭包的 Scope，确认是否包含 this、vm（Vue）、props（React）或大数组；
- 检查代码中所有 setInterval 调用点，确认是否都有对应 clearInterval，且调用时机在组件销毁前；
- 不要依赖“记得清”，必须显式保存 ID 并在 useEffect 清理函数、beforeUnmount 或页面跳转前执行清除。
切断引用链的关键动作不能只靠“设 null”
手动置 null 有效，但有严格前提：必须在闭包还能访问到该变量的作用域内完成，且变量名要和闭包捕获的一致。
- 对 DOM 节点、大型数组/对象、被闭包长期捕获的局部引用，才需要主动赋值 null；
- 错误示范：在闭包外写 test = null，但闭包内部用的是 const data = largeArray —— data 依然活着；
- 正确做法：在 useEffect 清理函数里写 element = null 或 largeData = null；
- 如果闭包是返回函数，得暴露一个 destroy 方法来触发清理，不能指望自动释放。
