DOM节点超2000是Chrome Layout耗时跃升的明确信号，低端安卓机layout时间常从80ms暴涨至320ms；须用document.querySelectorAll('*').length精准测量，而非源码推测。
查 DOM 节点总数是否超 2000
超过 2000 个节点是 Chrome Layout 阶段耗时跃升的明确信号，不是“可能卡”，而是低端安卓机 layout 时间常从 80ms 暴涨至 320ms。别看源码缩进，直接运行：document.querySelectorAll('*').length——这是唯一轻量、可靠的总数指标。
常见错误现象：
- 页面滚动变卡，但 JS Heap 曲线平稳 → 很可能是纯 DOM 节点膨胀
- Performance Monitor 中
DOM Nodes曲线只增不减或阶梯式上升 → 已发生 DOM 泄漏 - 用
document.querySelectorAll('body *').length替代 → 漏掉 Shadow DOM 和 iframe 内节点，结果失真
实操建议：
- 右键最外层容器 → Copy outerHTML → 粘贴到编辑器，用正则
]*>统计标签数（注意排除注释和空格干扰） - 重点盯三类高危结构：
<div> 套 <code><div> 套 <code><div>（只为 margin 居中）、<code><ul></ul>渲染表单项、SSR 自动注入的空<div class="wrapper"> <h3>查 DOM 深度是否 ≥6</h3> <p>DOM 深度 ≥6 时，<code>getComputedStyle()耗时翻倍，低端机单次调用卡顿超 80ms——这是浏览器递归匹配祖先链的硬开销，无法靠压缩或 CDN 缓解。立即学习“前端免费学习笔记（深入）”；
别靠肉眼数嵌套，也别猜组件编译后加了几层。打开 Chrome DevTools → Elements 面板 → 右键任意节点 → Show DOM properties，直接看
node.depth值。实操建议：
- 执行这段脚本快速定位所有深度 ≥6 的节点：
[...document.querySelectorAll('*')].filter(el => el.nodeType === 1 && el.depth >= 6).forEach(el => console.log(el.tagName, el.depth, el)) - 重点关注：Vue/React 编译后多出的根
<div>、BEM 类名诱导的深层选择器（如 <code>.a .b .c .d）、浮动清除层、冗余语义包裹 - 重构优先级：删掉
<div class="main"><div class="container"><div class="row"> 这类三层 wrapper，改用 <code><main></main>+display: grid查未闭合/非法嵌套标签引发的隐性错乱
页面错位、样式失效、JS 找不到元素？八成不是 CSS 写错了，而是某个
<div> 或 <code><section></section>忘写
- 执行这段脚本快速定位所有深度 ≥6 的节点：
