用DevTools底部Performance Monitor浮层可实时查看DOM节点总数，它持续显示DOM Nodes曲线，数字即当前所有已挂载节点（含textNode和commentNode），启用路径为右下角三点→More Tools>Performance monitor。
DOM 节点数超过 2000 个可见节点后，Chrome 中 getBoundingClientRect() 等布局 API 耗时会非线性飙升，帧率明显下跌——这不是理论值，是实测可复现的物理拐点。
怎么实时看当前 DOM 节点总数
别靠 $$('*').length 或肉眼数，用 DevTools 底部的 Performance Monitor 浮层最直接：它持续显示 DOM Nodes 曲线，数字就是当前所有已挂载节点（含 Text 和 Comment 节点）。
- 没开？右下角三个点 → More Tools > Performance monitor 即可启用
- 它不区分是否
display: none或visibility: hidden，只要在树里就算 -
document.querySelectorAll('body *').length会漏掉 Shadow DOM 和 iframe 内节点，慎用 - 上线前加一行监控逻辑：
setInterval(() => console.log('DOM nodes:', document.querySelectorAll('*').length), 5000)，日志留痕
为什么节点数涨了但页面没卡
节点多 ≠ 卡顿，但节点深度嵌套 + 频繁读取布局属性 = 必卡。比如一个 div 包着 10 层嵌套，里面再放 200 个 span，哪怕只改其中 1 个 textContent，浏览器也要回溯整个继承链计算样式。
- 深度超过 3 层时，
getBoundingClientRect()耗时增长不是线性，是指数级（实测 Chrome 126 下从 0.1ms → 3.7ms） - 即使元素
display: none，只要还在 DOM 树里，就参与 CSSOM 构建和继承链回溯 - Canvas/WebGL 容器上叠的 HTML overlay（图例、tooltip、坐标标尺）是重灾区，几百个节点堆起来还不自知
节点数飙高时，优先查这三类泄漏源
不是所有节点增长都算 bug，但以下三类基本等于泄漏：
立即学习“前端免费学习笔记（深入）”；
-
setInterval里反复appendChild()却没removeChild()：常见于轮播图、实时状态条 - Vue/React 组件销毁后，
addEventListener没解绑，导致对应 DOM 节点被闭包强引用，变成detached状态（DevTools Memory 面板拍快照后搜Detached DOM tree可见） - 全局
Map缓存了已移除节点，如window.nodeCache.set(id, el)，但没在el.remove()后同步delete
查的时候别只看总数，重点看操作闭环后是否回落：打开弹窗 → 关闭 → 等 1 秒 → 看 DOM Nodes 曲线有没有回。
