html嵌套超4层会显著拖慢首屏，因每层增加dom节点创建、样式继承查找及布局重排开销，实测低端设备fcp延迟可达80ms+；应控制在3–4层内，优先用语义标签与table-layout:fixed等优化手段。
HTML标签本身不“慢”，但错误的标签选择和嵌套方式会直接触发浏览器更重的解析、样式计算与重排重绘——这不是理论瓶颈，而是你在 DevTools 的 Rendering 面板里能亲眼看到的帧率掉帧、Layers 面板里炸开的合成层、Performance 面板中突起的 Recalculate Style 和 Layout 任务。
为什么嵌套超过4层会让首屏变慢
浏览器解析 HTML 是流式构建 DOM 树的过程，每多一层嵌套，就多一次节点创建 + 父子关系绑定 + 样式继承链查找。尤其当嵌套中混用 position: relative、transform 或 will-change 时，浏览器不得不为每一层生成独立的包含块（containing block），并反复重算布局边界。
- 用 DevTools → Elements 面板右键节点 → “Show DOM properties”，查
node.depth；超过 6 层就该被质疑必要性 <div><div><div><div> <p> 这类结构在低端安卓机上可能让 FCP 延迟 80ms+ </p> <li>语义标签如 <code><section></section>、<article></article>不减少节点数，但能缩短样式匹配路径——浏览器对它们有预设的默认样式继承策略，跳过部分通用规则遍历- 必须配合显式列宽：要么在
<col>上设width，要么给第一行<th> 或 <code><td> 设 <code>width，否则行为退化回auto - 注意：如果单元格用了
white-space: pre-wrap或含大量换行文本，fixed可能导致内容溢出或截断——此时宁可分页，别硬撑 - 必须带显式尺寸：
height、min-height或max-height（height: auto不行） - Flex/Grid 容器里子项写了
min-height: 300px，但父级没设高度？检查 Computed 面板里实际height是不是0 - 在
position: absolute或transform元素上加contain: layout paint，可能意外裁剪内容——因为layout会重置其包含块计算逻辑 - 典型安全组合：
content-visibility: auto加在列表容器（如<ul class="item-list"></ul>），再给每个<li>单独加contain: layout paint - 禁止操作：对
content-visibility: auto容器再设contain: size——这会让contain-intrinsic-size失效，浏览器无法预估占位高度，滚动时会抖动 - 特别注意：
display: contents或visibility: hidden元素上设content-visibility无效，规范明确不支持
table-layout: fixed; 在表格渲染中到底管不管用
默认 table-layout: auto 要求浏览器扫描整张表所有 <td> 内容（包括换行、字体宽度、内边距）才能确定列宽；一旦数据量上升（比如后台导出的 100 行 × 12 列报表），这个过程就会卡住主线程。
<ul>
<li>加 <code>table-layout: fixed 后，浏览器只读第一行或 <col> 定义，列宽秒定，后续行直接按比例分配空间
contain: layout paint 为什么加了没反应
contain 不是开关，而是契约：你声明“我这个容器自己管自己”，浏览器才敢跳过它参与全局布局和绘制计算。但它要求你先给出明确边界，否则静默忽略。
content-visibility: auto 和 contain 能不能一起用
能，但必须分层——content-visibility: auto 控制是否跳过渲染，contain: size 控制是否跳过尺寸计算，二者目标冲突，不能套在同一元素上。
真正卡顿往往来自“以为加了 contain 就万事大吉”——它只对已知尺寸、无 JS 动态改高的区域生效；而现代框架里满屏的 height: auto + useEffect resize 监听，恰恰是它的失效温床。
