dom深度超6层时样式计算明显变慢，因浏览器从右往左匹配选择器需向上回溯祖先节点，深度≥7则单次计算多耗0.5ms以上，易导致60fps动画掉帧。
DOM深度超6层时，样式计算明显变慢
Chrome DevTools 的 Style Recalc 阶段能直接观测到：DOM树节点深度每增加1层，浏览器匹配选择器时向上回溯的祖先检查就多一次。深度超过6层后，单次样式计算常多耗0.5ms以上——对60fps动画来说，这已足够导致掉帧。
这不是理论值，而是真实可测的开销。用 DevTools → Elements → 右键节点 → Show DOM properties 查看 nodeDepth，一旦 ≥7，就要警惕。
-
main article time这类后代选择器，浏览器先找所有time元素，再逐层向上确认父级是否为article、再确认其父级是否为main - 无语义嵌套（如
div > div > div > p）迫使你写脆弱选择器，HTML微调就得同步改CSS - 语义标签（
article、section）本身不增开销，但能让选择器从.wrapper .content p缩减为article p，匹配路径更短
深层嵌套放大CSS选择器的匹配成本
浏览器解析CSS选择器是“从右往左”执行的，不是从左往右。这意味着越靠右的选择器部分，匹配基数越大；而越靠左的部分，决定的是“要向上查几层”。深层结构让左侧约束条件变得昂贵。
比如 .card .body .title，浏览器会先收集所有 .title 元素，再对每个元素检查其父级是否有 .body，再检查该父级的父级是否有 .card。如果DOM深度已达7层，这个“向上查2层”的动作可能要穿越4个中间无意义 div。
- 表格内嵌套
div是重灾区：table td div p会让单元格内样式计算成本陡增 -
:last-of-type等伪类完全依赖DOM层级关系，结构一乱，行为就不可控 - 避免
div > div > div > input这类选择器——它不只慢，还意味着你本可以用form input或.field input替代
扁平结构不等于删标签，而是用CSS承担视觉层级
压平DOM不是把所有 div 删掉，而是把原本靠嵌套表达的布局、间距、状态，转交给CSS控制。关键在于“谁负责视觉，谁负责结构”。
- 用
display: grid+grid-template-areas实现卡片/页头/侧栏布局，1层DOM即可，无需div.wrapper > div.container > div.row > div.col - 图标+文字组合，改用
<svg></svg>文本，而非三层div堆叠 - 清除浮动不用
<div class="clearfix"></div>，改用::after { content: ""; display: table; clear: both; } - 分隔线用
border-bottom或伪元素，不额外加<hr>或<div class="divider"></div>
内联关键CSS不能替代结构优化
即使你把首屏CSS全内联进 <style></style>，如果DOM深度仍达8层，Style Recalc 和 Layout 阶段依然会慢。内联解决的是CSSOM构建阻塞，治不了DOM树本身带来的继承开销和回溯成本。
尤其在低端设备上，color、font-size 这类继承属性需逐层向上查找，深度越大，继承链越长；React/Vue 的 diff 也受虚拟DOM深度影响，最终映射到真实DOM的patch效率。
- SSR模板生成的冗余 wrapper（如
<div class="page"><div class="main"><div class="container">…）是最常见的无效深度来源 <li>表单控件别套三层 <code>div，用<label class="input-group"><input></label>语义更清、DOM更浅、选择器更稳 - 真正危险的不是节点总数，而是“无效嵌套层数”——100个同级
div比10个5层嵌套快得多
实际项目里最容易被忽略的一点：DOM深度问题往往藏在组件库或UI框架的默认模板中，而不是你自己手写的HTML。重构时优先检查第三方组件的渲染输出，而不是盯着自己写的那几行。
