dom深度超过6层时布局耗时非线性上升、getcomputedstyle延迟翻倍，因每层需样式继承、属性回溯与布局上下文创建，压平dom（用flex/grid替代嵌套容器）比压缩js更直接提升首屏性能。
DOM 深度超过 3 层，布局耗时就进入非线性上升区间；超过 6 层时，getComputedStyle 调用可能翻倍延迟，强制同步布局风险陡增——压平 DOM 是比压缩 JS 更直接有效的首屏提速手段。
为什么深度比节点数量更拖慢渲染
浏览器构建渲染树时，每个父节点都要为子节点做样式继承、属性回溯、布局上下文创建。深度每 +1，这些操作就多一层嵌套开销。100 个同级 div 的开销，远小于 10 个嵌套 5 层的结构。
常见现象包括：
-
document.querySelector('.a .b .c .d')在深度 >6 的 DOM 中匹配极慢：浏览器从右往左回溯，每一层都要检查父链 - CSS 继承属性（如
color、font-size）需逐层向上查找，链越长，样式计算越慢 - React/Vue 的虚拟 DOM 树深度仍映射真实 DOM 深度，间接拖慢 patch 性能
哪些结构最容易堆出无效深度
问题不在语义标签本身，而在“为对齐/间距/状态控制”硬加的包裹层。高频冗余模式包括：
- 表单控件：
<div><div><div><input></div></div></div>→ 实际只需<label class="input-group"><input></label> - 卡片组件：
card-inner → card-body → card-content，多数可合并为单层 - SSR 模板生成的空 wrapper：
<div class="page"><div class="main"><div class="container"><div class="row"><div class="col"> —— 实际只有一处用到 <code>col类，其余全是冗余怎么真正压平 DOM 深度
不是删标签，而是把视觉结构交给 CSS 承担。关键动作是「把本该由 DOM 表达的层级，转成由 CSS 布局属性表达」：
- 用
display: flex或grid替代多层div容器定位，1 层 DOM 就能实现复杂布局 - 图标+文字组合改用内联文本，而非
<div> <div><svg></svg></div> <div>文本</div> </div> - 清除浮动不用
<div style="clear:both"></div>，改用overflow: hidden或display: flow-root - 分隔线用
border-bottom或::before/伪元素，不额外加<hr>或<div class="divider"> <h3>怎么验证深度是否真的降下来了</h3> <p>别只看代码，要测真实渲染树深度：</p> <ul> <li>Chrome DevTools → Elements 面板，右键任意节点 → <strong>Show DOM properties</strong>，查看 <code>depth值，超过 6 就要警惕 - 配合 Layout 阶段耗时观测：Performance 面板录制一次页面加载，重点看 Layout 时间是否随深度降低明显下降
- 某些框架（如 SSR 渲染）会注入不可见 wrapper，它们虽不渲染，但仍参与 DOM 构建和样式计算，必须一并清理
最常被忽略的是：即使用了
transform或will-change，深层 DOM 依然在样式计算和布局阶段持续消耗 CPU——优化必须落到真实节点结构上，不能只靠合成层绕过。 - 用
