DOM深度超过3层会导致布局耗时指数级上升，因每增一层都加重样式继承、属性回溯和布局上下文创建开销；需压平至3层内，用CSS布局替代冗余DOM嵌套，并通过Chrome DevTools的node.depth验证真实深度。
DOM 深度超过 3 层，布局耗时就不是线性增长，而是指数级卡顿——这不是优化建议，是 Chrome Layout 阶段可直接观测到的性能事实。
DOM 深度比节点数量更致命
浏览器构建渲染树时，并不按“总节点数”算账，而是对每个父节点重复执行样式继承、属性回溯、布局上下文创建。深度每 +1，这些嵌套操作就多一层开销。100 个同级 div 的开销，远低于 10 个嵌套 5 层的结构。
-
document.querySelector('.a .b .c .d')在深度 >6 的 DOM 中匹配失败时，浏览器需从右往左逐层验证父链，回溯成本陡增 - CSS 继承属性（如
color、font-size）要向上遍历整条链，链越长，样式计算越慢 - React/Vue 的虚拟 DOM diff 仍映射真实 DOM 深度，深层结构会间接拖慢 patch 性能
- 服务端模板（如 SSR）常悄悄注入不可见 wrapper，比如
<div class="page"><div class="main"><div class="container">，它们参与样式计算但不渲染，必须一并清理
怎么真正压平 DOM 结构
不是删标签，而是把本该由 DOM 表达的层级，转成由 CSS 布局属性表达。视觉结构交给 CSS，DOM 只保留语义和必要容器。
- 用
display: grid+grid-template-areas替代多层div容器定位，1 层 DOM 就能实现复杂布局 - 图标+文字组合改用内联
svg+ 文本，而非三层div套娃：<div><div><svg></svg></div><div>文本</div></div> - 清除浮动不用
<div class="clearfix"></div>，改用伪元素：::after { content: ""; display: table; clear: both; } - 分隔线用
border-bottom或::before，不额外加<hr>或<div class="divider"> - 表单控件避免
<div><div><div><input></div></div></div>，改用语义化<label class="input-group"><input></label>，靠gap和flex控制间距
验证深度是否真降下来了
别只看源码缩进，要测真实渲染树深度。
立即学习“前端免费学习笔记（深入）”；
- Chrome DevTools → Elements 面板，右键任意节点 →
Show DOM properties，查看depth值；超过 6 就得重构 - Performance 面板录制加载过程，重点观察
Layout阶段耗时是否随深度降低明显下降 - 用
getComputedStyle(el)测速：在深度 >6 的节点上调用，耗时可能翻倍；压平后应显著回落 - 注意：某些框架注入的空 wrapper（如 SSR 生成的
data-reactroot父容器）虽不显式渲染，但仍计入 depth，必须识别并剔除
最常被忽略的是：DOM 深度降下来后，JS 引用没断——element.remove() 只摘树，不销毁；node = null 和 removeEventListener 必须配对执行，否则节点仍在内存中“活着”。
