通过分析retainers中gc root到dom的路径长度、closure出现位置及顶层持有者类型，可判断dom是否被长生命周期闭包意外捕获；路径越深、closure越早出现、顶层为window/setinterval/document.addeventlistener等长期对象，泄漏越明确。
重点看保留树底部三到四层
保留树不是“谁引用了它”，而是“谁不让它死”。真正决定 DOM 片段能否释放的，是离 GC Root 最近的那几个持有者：
- 如果最底层是 Window、globalThis、setInterval、setTimeout 或 document.addEventListener 这类全局/长期存活对象，说明该 DOM 已被“钉”在内存里
- 紧接着往上若出现 (closure)，且这个 closure 没有对应清理逻辑（比如没调用 removeEventListener 或 clearTimeout），基本可断定是泄漏源头
- 再往上若看到 this、ref.current、vm.$el 或某个 Service 实例，说明闭包不仅捕获了 DOM，还连带锁住了整个上下文
识别“不该存在的闭包层级”
正常情况下，DOM 节点的保留路径应该短而清晰：比如 Document → ParentNode → ChildNode。一旦路径中插入一个本该随组件卸载就消失的 closure，就是危险信号：
- 路径中出现 [[Scopes]] → Closure → HTMLDivElement：说明该 DOM 是函数执行时局部作用域里的变量，却被闭包长期持有
- closure 下方紧跟着 data、state、cache 等字段名：表明闭包同时捕获了数据和 DOM，两者被一起卡住
- 同一 closure 在多个 Detached DOM 的 Retainers 中重复出现：说明一个闭包正拖着整棵子树不放
对比快照确认路径是否“异常延长”
单看一张快照容易误判，必须对比操作前后的变化：
- 在组件挂载后拍第一张快照，关闭组件后再拍第二张，切到 Comparison 视图
- 筛选 HTMLDivElement 并勾选 Show detached elements only
- 点击任一 Detached 节点，在 Retainers 中观察：如果路径比基线快照多出 2 层以上，且新增层含 (closure) 或 Map/Set，大概率是缓存或监听器未清理
快速验证闭包是否“多拿了东西”
闭包本身合法，问题在于它捕获的对象是否超出必要范围：
- 检查闭包函数体：是否直接访问了 this、ref.current、document.getElementById 返回值？这些都可能指向已移除但未解绑的 DOM
- 检查闭包外层作用域：是否有大型数组、响应式 state、第三方库实例（如 Lodash throttle）被一并闭包？它们会让 DOM 陪葬
- 改写建议：把 DOM 当参数传入回调，而不是在闭包里捕获——fn = (el) => el.innerHTML = 'x'，而非 const el = ...; const fn = () => el.innerHTML = 'x'
