Detached节点线性增长是DOM泄漏的铁证，用$$('*').length初筛最可靠；Performance面板Nodes曲线持续攀升、内存快照中Detached节点Delta为正且Retainers显示闭包引用，即可锁定泄漏源。
动态更新 HTML 文档结构（比如 innerHTML = response、hx-swap、React.setState）本身不一定会泄漏，但只要更新后旧节点没被彻底断开引用，Detached 节点数就会随操作线性增长——这是泄漏已发生的铁证，不是“可能”。
用 $$('*').length 快速确认是否真在漏节点
这是最轻量、最不可替代的初筛手段，比看内存 MB 数靠谱十倍：
- 打开 DevTools Console，执行
$$('*').length记下基线值（比如1247892） - 执行一次闭环操作：打开弹窗 → 异步加载内容 → 关闭弹窗 → 等待 2 秒
- 再跑一次
$$('*').length，若变成1251346，且重复 3 次后每次 +3000+，基本锁定泄漏 - 注意：
document.querySelectorAll('body *').length不计入 Shadow DOM 和 iframe 内节点，结果失真；$$是 DevTools 原生 API，覆盖全
Performance 面板盯 Nodes 曲线，比 JS Heap 更早暴露问题
Nodes 曲线反映的是当前存活 DOM 节点总数，是原生引用计数，只要节点没释放，它立刻拉高：
- 勾选 Performance 面板的
Memory和Screenshots，录制前先手动 GC（点垃圾桶图标） - 只做目标操作：比如点按钮 → 渲染表格 → 关闭 → 等待 2 秒，避免切 Tab 或滚动干扰
- 停止后重点看灰色柱状图
Nodes：如果每次操作后峰值都比上一轮高，且回落不到初始水平，就是泄漏铁证 - 别纠结单次没回落——DOM 渲染有延迟，等 1–2 秒再看；但连续 3 次回落失败，不用犹豫
Memory 面板拍堆快照，专找 Detached HTMLDivElement 及其保留路径
泄漏节点往往已从文档树移除，却因 JS 引用卡在内存里，表现为 Detached 类型：
立即学习“前端免费学习笔记（深入）”；
- 拍第一张快照（
Snapshot #1），执行疑似泄漏操作（如加载含 5000 条数据的表格） - 立刻拍第二张（
Snapshot #2），切换到Comparison视图 - 在
Constructor列筛选HTMLDivElement、Text、Comment，看Delta是否为正且数量异常（比如多出4821个） - 点开任一
Detached节点，在右侧Retainers里顺藤摸瓜：若出现Closure → function → (anonymous) → element，说明是事件监听器里的闭包没清理
removeEventListener 失效？根源常是函数引用不一致
异步更新后 DOM 被替换，但旧监听器没被移除，核心问题在于浏览器认为两次绑定的函数不是同一个对象：
- ❌ 错误写法：
el.addEventListener('click', () => { doSomething(); });—— 每次都生成新函数，removeEventListener找不到原引用 - ✅ 正确写法：
const handler = () => { doSomething(); };+el.addEventListener('click', handler)+el.removeEventListener('click', handler) - React 函数组件中，
useCallback必须写全依赖项，漏写[props.id]就会导致每次渲染都生成新函数 - HTMX 场景下，避免用
hx-on绑定匿名函数；改用具名函数 + 手动解绑，或加{ once: true }明确声明一次性
Detached 节点是否线性增长，才是判断泄漏的核心标尺；而 Retainers 里那个 Closure → function → element 链路，往往就藏在你没意识到的事件绑定或定时器回调里——它不声不响，但每轮操作都在复制一份。
