$$('*').length持续上涨才是DOM泄漏真信号，需执行闭环操作后对比数值是否线性增长；Performance面板Nodes曲线验证回落趋势；Memory面板堆快照Comparison筛选Detached HTMLDivElement并追踪Retainers路径定位闭包或缓存未清理问题。
海量节点网页的内存飙升，90%不是 DOM 节点本身撑爆内存，而是节点被 JS 强引用卡住不释放——$$('*').length 持续上涨才是真信号，任务管理器里 MB 数涨了未必是泄漏。
怎么用 $$('*').length 快速确认是不是真在漏节点
这是最轻量、最不可替代的初筛动作，比看内存 MB 数靠谱十倍。
- 打开 Chrome DevTools → Console，执行
$$('*').length记下基线值（比如 142856） - 执行一次闭环操作：打开列表页 → 滚动加载 5000 条 → 点返回 → 等待 2 秒
- 再跑一次
$$('*').length，若变成 145921，且重复 3 次后每次 +2500~3000，基本锁定泄漏 - 注意：
document.querySelectorAll('body *').length不计入 Shadow DOM 和 iframe 内节点，而现代框架/游戏/弹窗常嵌套这些，$$是 DevTools 原生 API，结果更真实
Performance 面板里盯 Nodes 曲线，不是 JS Heap
JS Heap 涨得慢、GC 可能延迟；Nodes 曲线是原生 DOM 引用计数，节点没释放它立刻拉高。
- 打开 Performance 面板 → 勾选
Memory和Screenshots - 录制前先点右上角垃圾桶图标手动 GC，确保起点干净
- 只做目标操作（如：进战斗页 → 出战斗页 → 等 2s），避免切 Tab 或滚动无关区域
- 停止后重点看灰色柱状图
Nodes：如果每轮峰值都比上一轮高，且结束时回落不到初始值，就是泄漏铁证 - 别纠结单次没回落——DOM 渲染有延迟，等 1–2 秒再看；但连续 3 次回落失败，不用犹豫
Memory 面板拍堆快照，专找 Detached HTMLDivElement 和保留路径
泄漏节点往往已从文档树移除，却因 JS 引用卡在内存里，表现为 Detached 类型。这是定位根源的唯一可靠方式。
Article To Html
下载
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
立即学习“前端免费学习笔记（深入）”；
- Memory 面板 →
Capture heap snapshot（Snapshot #1） - 执行疑似泄漏操作（如：渲染完万级表格后销毁容器）→ 立刻拍第二张（Snapshot #2）
- 切换到
Comparison视图，在Constructor列筛选HTMLDivElement、Text、Comment，看Delta是否为正且数量异常（比如 +1247） - 点开任一
Detached节点 → 右侧Retainers里顺藤摸瓜：若出现Closure → function → (anonymous) → element，说明是事件监听器闭包没清理；若路径末尾是window.cacheMap → Map → key → element，就是全局缓存惹的祸
常见泄漏场景与修复关键点
修复不是“删掉 DOM”，而是切断 JS 对已移除节点的强引用。
-
addEventListener绑了箭头函数？() => {}每次都是新函数，removeEventListener找不到原引用——必须用具名函数或useCallback并写全依赖项 - 用了
DocumentFragment却把它存在闭包里长期持有？fragment 插入后自动清空，继续持有它等于锁住整棵子树 - 全局
Map或WeakMap缓存了节点？普通Map会阻止 GC；WeakMap安全，但若你用节点作 key 却又把 value（比如大数据对象）反向 hold 住节点，照样泄漏 - Canvas/WebGL 上下文没清理？
context.clearRect()+context = null+canvas.width = 1才算真正释放像素数据
真正难的不是发现泄漏，而是判断哪些引用是“合理持有”、哪些是“该断不断”。比如虚拟滚动中缓存视口外节点用于快速复用，这本身没问题；但若缓存逻辑没随组件卸载清除，就变成钉子。这类边界，得靠 Retainers 里每一层引用链来验证。
