chrome devtools 中通过 elements 面板右键节点选“show dom properties”查 node.depth，超6需优化；body直系子元素数远超视觉区块数表明包裹层泛滥；语义标签（header/nav/main）可加速解析；grid/flex 用于减少dom嵌套；禁用 display: contents；表格仅用于真实行列数据。
Chrome DevTools 里怎么看 DOM 深度是否超标
别数源码里的 <div> 层数，浏览器解析的是最终 DOM 树。打开 Elements 面板，右键任意节点 → “Show DOM properties”，查 <code>node.depth 值：超过 6 就该停下手来检查；如果首页的 直接子元素数量远大于视觉区块数（比如只该有 3 块，却返回 8），说明包裹层泛滥。
语义标签不是“加分项”，是解析加速器
浏览器对 <header></header>、<nav></nav>、<main></main> 的解析路径比 <div class="header"> 更短——它不用反复回溯确认层级关系，也不用为每个同级 <code><div> 单独做样式继承链推导。
<ul><li>把 <code><div class="main-header"> 改成 <code><header class="main-header"></header>，类名保留，标签换掉
<div class="nav-list"> → <code><nav class="nav-list"></nav>，但注意 <nav></nav> 下直接放 <a></a> 或 <ul></ul>，别再套一层 <div>
<li>避免混用：<code><section><div>
<h2> 是错的，<code><h2></h2> 应该是 <section></section> 的直接子元素
Grid/Flex 不是“更酷的写法”，是删 DOM 节点的工具
三列等宽布局，老写法要三层嵌套：<div class="row">
<div class="col">A</div>
<div class="col">B</div>
<div class="col">C</div>
</div>；新写法一层搞定：<main style="display: grid; grid-template-columns: 1fr 1fr 1fr;"><section>A</section><section>B</section><section>C</section></main>。
- Flex 适合一维排列（导航栏、按钮组），别在 Flex 容器里再套 Grid 微调——这通常说明模块切分没想清楚
- Grid 适合二维分区（仪表盘、卡片流），但必须显式声明
grid-template-rows，否则隐式轨道会触发多次重排 - 禁用
display: contents做“视觉扁平化”：它剥离可访问性树节点，IE 全系不支持，且会让getComputedStyle()返回空对象
表格布局不是“过时”，是语义误用的性能炸弹
<table> 自带隐式 IFC，但单元格内再套 <code><div> + <code>flex，会触发额外 BFC 创建，导致每行都单独重排；更糟的是 table-layout: auto 会让浏览器扫描全部单元格内容才能定列宽，50 行 × 10 列的表格可能卡顿明显。
- 仅当数据具备明确行列语义（如财务报表、课程表）时才用
<table> <li>设 <code>table-layout: fixed后，浏览器只看第一行或<col>定义，列宽秒定 - 绝对不要用
<table> 实现页头/侧边栏/主内容这种页面结构——<code><main></main>+grid更轻、更快、更语义 实际改完后，DOM 节点数下降 30% 可能只带来 10–15ms 解析提速，但深层嵌套带来的样式继承链拉长、合成层碎片化、重排范围扩大，这些才是低端设备上“卡半秒”的真正推手。改结构不是为了炫技，是让浏览器少做几件事。
