dom节点总数超2000或深度超6层会引发非线性layout卡顿，实测于chrome devtools及低端安卓机、ssr首屏场景；spa首屏建议≤500，整页硬性约束2000以内。
document.querySelectorAll('*').length 超过 2000 就会卡帧
这不是建议，是 Chrome DevTools 里可复现的物理拐点：DOM 节点数一旦超过 2000，getBoundingClientRect()、offsetTop 等布局 API 耗时非线性飙升，实测从 0.1ms 拉到 3.7ms（Chrome 126），帧率直接掉到 30fps 以下。Canvas/WebGL 容器上叠的 HTML overlay（图例、tooltip、坐标标尺）最容易无声无息堆到这个量级。
低端安卓设备上 500 是首屏硬约束
在联发科 Helio A22、2GB RAM 的机型上，document.querySelectorAll('*').length 达到 2000 后 layout 耗时从 15ms 跳到 60ms+；而首屏内容若超 500 节点，JS 执行 + layout 合计大概率突破 100ms，用户明显感知延迟。注意“首屏”指 viewport 内实际渲染内容，不含 v-if 未激活分支或懒加载区域。
DOM 深度比总数更危险：node.depth > 6 必须砍
深度超 6 层时，getComputedStyle() 平均耗时翻倍；深度达 12，低端安卓单次调用可能卡顿 80ms 以上——浏览器要递归回溯祖先链计算样式、继承属性和布局上下文。常见高危结构：body > div > div > div > .content > .list > .item（深度 7），纯 class 堆叠却毫无语义。DevTools → Elements 面板右键节点 → “Show DOM properties” 可直接看 node.depth 值。
CI 中必须加自动化断言守住底线
靠人手动跑 document.querySelectorAll('*').length 不现实，也容易漏掉 SSR 或 hydration 后的真实节点数。Puppeteer/Playwright 测试脚本里加这一行：
expect(await page.$eval('body', el => document.querySelectorAll('*').length)).toBeLessThan(2000)
对首屏页面单独校验更稳妥，比如只测 #dashboard-container 下的节点数。别信源码“看着不多”，构建后 HTML 常因框架默认包裹、CMS 模板拼接膨胀出几百个无功能 wrapper。
真正难的不是数清数字，而是每次写 <div class="wrapper"> 之前，问一句：这个 wrapper 真的必要吗？一旦容忍一个，后面就批量复制。</div>
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
