dom深度超3层会导致布局耗时非线性上升，因每增一层均增加样式继承、属性回溯和布局上下文创建开销；深度>6时getcomputedstyle等api耗时翻倍，强制同步布局风险陡增，故应压平至3层内并用css替代冗余包裹。
DOM 深度超过 3 层，布局耗时就不是线性增长，而是指数级上升；真正卡首屏、拖动画的，往往不是节点总数，而是嵌套层数本身。
为什么深度比数量更致命
浏览器构建渲染树时，每个父节点都要为子节点做样式继承、属性回溯、布局上下文创建。深度每 +1，这些操作就多一层嵌套开销——而 100 个同级 div 的开销，远小于 10 个嵌套 5 ayer 的结构。
-
document.querySelector('.a .b .c .d')这类选择器在深度 >6 的 DOM 中匹配失败成本极高：浏览器从右往左回溯，每一层都要检查父链 - CSS 继承属性（如
color、font-size）需逐层向上查找，链越长，样式计算越慢 - React/Vue 的 diff 算法虽能跳过部分节点，但虚拟 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 布局属性表达」：
- 用
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 依然会拖慢样式继承、选择器匹配和初始 layout 计算——这些开销发生在合成层创建之前，无法绕过。 - 用
