HTML解析引擎在处理海量DOM节点时的垃圾回收GC频率监测实战

Performance面板通过Nodes曲线盯GC频率：录制前手动GC清基线，勾选Memory和Screenshots，执行闭环操作后观察Nodes柱状图——若每轮峰值递增且回落不到基线，或1秒内陡降超3次，即暴露泄漏与掉帧风险。

怎么用 Performance 面板盯住 GC 频率

GC 频率本身不是问题，但密集、耗时、发生在交互帧内的 GC 才是中端设备卡顿的直接推手。Performance 面板里的灰色 Nodes 柱状图比 JS Heap 更早暴露泄漏——它反映的是 DOM 引用计数，只要节点没被真正释放，它立刻拉高。

实操建议：

立即学习“前端免费学习笔记（深入）”；

• 录制前先点右上角垃圾桶图标 Collect garbage，清空基线
• 勾选 Memory 和 Screenshots，只做目标操作（比如滚动加载 10 轮数据）
• 停止后重点看 Nodes 曲线：如果每轮峰值都比上一轮高，且回落不到初始值，就是泄漏铁证
• 注意锯齿密度：1 秒内出现 3 次以上陡降，中端机基本已掉帧

为什么 $$('*').length 比任务管理器更可靠

Chrome 任务管理器里内存涨了 200MB，可能是 GPU 纹理或字体缓存占的；但 $$('*').length 是真实 DOM 节点总数，只增不减就说明有节点没被回收。

实操建议：

立即学习“前端免费学习笔记（深入）”；

• 执行 $$('*').length 记下基线（如 1247892）
• 完成一次闭环操作（打开页 → 滚到底 → 返回 → 等 2 秒）
• 再跑 $$('*').length，若每次 +3000+ 且连续 3 次不回落，基本锁定泄漏
• 对比 document.querySelectorAll('body *').length，差 10 倍以上说明有 iframe 或 Shadow DOM 干扰，得单独查

堆快照里怎么快速定位 Detached 节点

Detached 节点是“已从文档移除但 JS 还强引用着”的典型泄漏信号。它们不渲染、不响应，却拖慢 GC、吃内存。

实操建议：

立即学习“前端免费学习笔记（深入）”；

• 拍第一张快照（空基线），执行一次插入操作（如渲染 5000 条列表）
• 立刻点 Collect garbage，再拍第二张快照
• 在 Comparison 视图筛选 HTMLDivElement、Text，看 Delta 是否为正且数量异常（比如多出 4821 个）
• 点开任一 Detached 节点，在右侧 Retainers 里顺藤摸瓜：若路径含 Closure → function → (anonymous) → element，说明事件监听器闭包没清理

大屏滚动场景下别信 disconnectedCallback

大屏里滚动复用节点时，disconnectedCallback 根本不会触发——浏览器认为“还是同一个节点”，不走生命周期。指望它清理定时器或事件监听器，等于放任泄漏。

实操建议：

立即学习“前端免费学习笔记（深入）”；

• 页面刷新、标签页切后台、滚动中反复 removeChild() + appendChild()，这三类场景下 disconnectedCallback 全部失效
• 实测某告警卡片组件因此泄漏 120+ 个 setInterval 实例，运行 8 小时后内存抖动明显
• 正确做法是用 Map 池化节点：node.style.display = 'none'（不 detach），靠 dataset.id 管理复用，更新内容而非重建

Detached 节点在快照里常藏得深，尤其当它们被闭包、全局 Map 或 IntersectionObserver 实例间接持有时，Retainers 路径可能跳转 3–4 层才暴露源头。手动 GC 后仍存活的节点，必须逐层点开 retainers 查，不能只看 constructor 名。