dom深度超6层会直接拖慢fcp 200ms以上，因浏览器流式解析时每层均强制执行dom创建、样式匹配与布局计算，低端安卓机实测首屏延迟突破200ms。
DOM深度超6层会直接拖慢FCP 200ms以上
不是“可能变慢”，而是低端安卓机上实测首屏绘制延迟突破200ms。浏览器流式解析HTML时，每层嵌套都强制执行一次DOM节点创建 + 样式匹配 + 布局计算，这三步在depth ≥ 6时开始叠加出可观测卡顿。
验证方式极简单：Show DOM properties右键任意节点就能看到depth值；别信“结构看起来不深”，<div data-reactroot>外层常被SSR框架无意加厚两层，<code><td>里再套<code><div>会触发表格重排放大效应。<ul><li>语义标签如<code><section></section>、<main></main>本身不增开销，但能天然替代三层<div class="wrapper">堆叠<li><code><table>单元格内禁用<code>display: flex或position: relative——它会让整行重排成本指数上升
Layout Shift Regions，滚动时若大面积连片闪动，大概率是深层嵌套+样式继承链过长深层嵌套让CSS选择器和继承计算变慢
浏览器匹配.deep .nested .wrapper .content这类选择器时，是从右往左回溯父链的。depth=6意味着每个匹配都要检查6级祖先，而color、font-size等继承属性也得逐层向上找，低端机上单次getComputedStyle()耗时可达3ms+。
更隐蔽的是通配符选择器：* { box-sizing: border-box; }会在每一层都做全局扫描，嵌套越深，匹配次数越多。
- 用
main > section > article代替.container .wrapper .content，减少层级依赖 - 避免在depth > 3的结构里用
@media嵌套或inherit值——它们会延长继承链判断逻辑 - 伪元素
::before/::after比额外<span></span>更轻量，尤其适合菜单箭头、状态标识等场景
递归渲染菜单时DOM深度失控的常见原因
ul→li→a本就是语义必需的三层，但开发者常在<a></a>外硬加<div class="link-wrapper">，瞬间拉到4–5层；PHP/Vue/React递归组件若没预处理数据，很容易输出<code><li><ul><li><ul>...</ul></li></ul></li>这种指数级嵌套。
关键不在删标签，而在控制生成逻辑：
- PHP递归函数必须传
$depth参数，且只返回本层<li>，子树HTML由调用方拼接 - Vue/React必须提前把扁平数组（含
parentId）转成树结构，不能在组件内实时遍历——否则O(n²)性能崩盘 - 原生JS拼菜单禁用
innerHTML +=，事件会丢失；改用document.createElement或insertAdjacentHTML保留已有绑定
HTML结构不合法直接导致样式失效
没或写错，浏览器进怪异模式，<code>flex、grid、calc()全失效；<nav><table>
<tr><th>Home</th></tr>这种错位嵌套，浏览器会强行纠错，结果<code>nav table tr th根本找不到节点。
结构松动比CSS写错更难调试——因为问题不在样式表里，而在DOM树根本没按你设想的方式构建。
- 执行
document.compatMode，返回CSS1Compat才算标准模式 <th>必须在<code><tr>内，<code><tr>必须在<code><tbody>或<code><thead>内，语义标签必须显式闭合<li>VS Code装“Auto Close Tag”插件，比靠肉眼检查靠谱得多</li> <p>真正卡顿往往藏在HTML结构里，而不是JS执行慢。depth值超过6之后，每多一层，布局耗时不是线性增加，而是开始非线性跳升——这点在Chrome DevTools的Layout面板里能直接看到帧率断崖。</p> </thead>
