dom节点数超2000会触发layout非线性卡顿，是chrome实测性能拐点；用$$('*').length精准测量，需排除注释/空文本节点及第三方sdk干扰，并在ci中自动化校验。
DOM 节点数超过 2000 就会触发 layout 阶段非线性卡顿，这不是警告，是 Chrome DevTools 里可复现的性能拐点——尤其在 Canvas/WebGL 容器中混用 HTML overlay 时，帧率下跌与节点数呈强相关，和 JS 执行快慢无关。
怎么快速测出当前页面真实 DOM 节点数
别信模板注释或“看起来不多”，直接看运行时真实数量：
-
$$('*').length是最轻量、最可靠的命令，DevTools Console 里一敲就出结果（注意不是document.querySelectorAll('*').length，前者是 DevTools 扩展 API，对 Shadow DOM 和 iframe 更鲁棒） - 如果两者差 5 倍以上，说明有 iframe 或自定义元素干扰，得单独进其
contentDocument或shadowRoot里再跑一遍 - 首屏节点数 ≠ 全页节点数：用
document.querySelector('body').getBoundingClientRect()结合elementFromPoint()粗筛 viewport 内节点，再用$$('body *:is(:visible)')过滤掉display: none或visibility: hidden的干扰项
为什么 2000 是硬门槛，而不是建议值
这个数字来自低端安卓设备实测数据，不是理论估算：
- 联发科 Helio A22 + 2GB RAM 设备上，
$$('*').length达到 2000 后，layout 阶段耗时从 15ms 跳到 60ms+，直接拖垮 60fps 渲染循环 - Canvas/WebGL 容器里混用 HTML overlay 时，哪怕 overlay 元素
display: none，只要它在 DOM 树里，就参与 CSSOM 构建和继承链回溯 - 深度 > 6 层时，
getComputedStyle()调用耗时翻倍；深度达 12，单次调用可能卡顿 80ms 以上——浏览器要递归回溯祖先样式，每深一层开销都叠加
CI 中如何自动化拦截超限 DOM
靠人每次手动检查不现实，必须塞进测试流程：
- Playwright 脚本里加断言：
expect(await page.$eval('body', el => $$('*').length)).toBeLessThan(2000) - 对首屏做专项校验：先
await page.waitForSelector('.main-viewport')，再执行$$('.main-viewport *:is(:visible)')计数，阈值设为 ≤500 - 配合 Puppeteer 的
page.metrics()抓 layout 时间，当LayoutDuration> 40ms 且节点数 > 1800 时自动失败并截图
DOM 数量监测容易被忽略的三个盲区
很多团队只盯着总数，却漏掉了真正拖垮性能的细节：
- 注释节点和空文本节点也会被
$$('*').length统计进来——服务端模板渲染后残留的换行缩进、v-if 未激活分支里的注释，全算 -
innerHTML插入未清洗的 HTML 字符串，会把服务端返回的空格、<div> 全部转成真实节点 <li>第三方 SDK（比如埋点、客服浮窗）动态注入的 wrapper，常带 <code>data-no-capture或data-ignore属性，但没被计入排除逻辑，实际占了上百节点却不显眼
