DOM节点总数超2000或深度超6层会引发非线性layout卡顿，实测于Chrome DevTools及低端安卓机、SSR首屏场景；SPA首屏建议≤500，整页硬性约束2000以内。
DOM 节点数没有浏览器硬性限制，但超过 2000 个可见节点后，Chrome 中 getBoundingClientRect()、offsetTop 等布局 API 耗时会非线性飙升，帧率明显下跌——这不是理论值，是实测可复现的物理拐点。
怎么实时看当前 DOM 节点总数
别靠肉眼数或截图猜，用 Chrome DevTools 底部的 Performance Monitor 浮层最直接：它持续显示 DOM Nodes 曲线，数字就是当前所有已挂载节点（含 Text 和 Comment 节点），不区分是否 visible，只要在树里就算。
没开的话，右下角三个点 → More Tools > Performance monitor 即可启用。操作前后盯住这个数字，比手动数标签快十倍。
临时验证可用：$$('*').length，但它只适合手动触发，无法持续观察波动；document.querySelectorAll('body *').length 结果可能略少——它漏掉 Shadow DOM 和 iframe 内节点。
立即学习“前端免费学习笔记（深入）”；
大屏上线前建议加一行监控逻辑：setInterval(() => console.log('DOM nodes:', document.querySelectorAll('*').length), 5000)，日志里留痕，方便回溯增长节奏。
为什么节点数涨了但页面没卡？你可能漏看了重排代价
节点多 ≠ 卡顿，但节点深度嵌套 + 频繁读取布局属性 = 必卡。比如一个 div 包着 10 层嵌套，里面再放 200 个 span，哪怕只改其中 1 个 textContent，浏览器也要回溯整个继承链计算样式。
- 深度超过 3 层时，
getBoundingClientRect()耗时增长不是线性，是指数级；实测从 0.1ms → 3.7ms（Chrome 126） - 即使元素
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 曲线有没有回降。没回落，大概率就是泄漏。
滚动监听里最容易踩的三类 DOM 操作坑
大屏滚动更新常卡在“看似合理”的操作上：
- 在
scroll回调里直接调用el.remove()→ 每帧触发回流 + 事件丢失 + 内存分配压力 - 用
getBoundingClientRect()或offsetTop判断是否出视口 → 强制同步 layout，一帧内多次调用直接拖慢 3–5ms - 滚动中反复
removeChild()+appendChild()已挂载过的节点，浏览器认为“还是同一个”，不触发disconnectedCallback，定时器和监听器滞留
真实场景里，节点数本身不是问题，问题在于谁在动、怎么动、动完有没有收尾——尤其是那些你以为“只是隐藏一下”的操作，很可能正悄悄把 layout 压力推到临界点。
