dom嵌套超4层即触发性能警觉，因浏览器深度优先解析导致耗时线性上升、css选择器匹配成本指数增长；script未加defer会阻塞html解析致白屏；语义标签缺失则损害seo与无障碍访问。
HTML文档结构不是“写完就能跑”的静态骨架，而是性能瓶颈的第一道关卡——DOM嵌套过深、语义错位、资源加载顺序混乱，会直接导致首屏白屏、辅助设备读不出、SEO抓取失败，甚至让后续JS执行都卡在解析阶段。
为什么 DOM 层级超过 4 层就该警觉
浏览器构建 DOM 树是深度优先遍历，每多一层嵌套，不仅解析耗时线性上升，CSS选择器匹配成本还会指数级增长。比如 .a .b .c .d p 这种四层后代选择器，浏览器要逐层回溯父节点，实际开销远超表面看起来的“只多一个点”。
- 单个
<section></section>下子元素超 50 个，滚动时重排（reflow）明显卡顿 -
<div><div><div><p></p></div></div></div>这类纯样式驱动的嵌套，99% 的场景下可以删掉中间两层 - 用开发者工具 Elements 面板按
Ctrl+Shift+C定位深层节点，重点查<div> 套 <code><div> 的区域 <li>Flex/Grid 能直接替代 2–3 层包裹容器，例如三栏布局用 <code>display: grid，无需外层<div class="row"></div>+ 三个<div class="col"></div> -
<script></script>默认阻塞解析；加defer才能等 HTML 解析完再执行（且保持顺序） -
async适合完全独立的脚本（如统计代码），不保证执行顺序，也不等待 DOM 构建完成 -
<link rel="stylesheet">必须放里，否则 CSSOM 构建延迟，触发 FOUC（闪白） -
<meta charset="UTF-8">必须在前 1024 字节内，否则某些 Safari 版本会乱码 -
<main></main>必须且只能出现一次，不可嵌套在<section></section>或<div></div>内 -
<nav></nav>应包裹导航链接，不是所有横向菜单都算<nav></nav>；广告位、无关链接组建议用<div role="complementary"> <li> <code><ul></ul>和<ol></ol>必须直接包含<li>，中间插<div> 会导致 NVDA/VoiceOver 读不出列表项数量 <li> <code><figure></figure>+<figcaption></figcaption>是图片/图表的正确容器，比<div class="img-wrap"></div>更利于可访问性和 SEO 提取
script 和 link 放错位置比代码写错更致命
一个没加 defer 的 <script src="app.js"></script> 放在 里，会立刻中断 HTML 解析：浏览器下载并执行完 JS 才继续，此时连 都没生成，用户看到的就是白屏。
语义化标签不是“锦上添花”，而是解析器和爬虫的指令集
<header></header> 不是 <div class="header"></div> 的高级写法，它是浏览器、搜索引擎、屏幕阅读器识别页眉的唯一可靠信号。混用 <section></section> 和 <article></article> 会让爬虫误判内容独立性，直接影响 SEO 权重分配。
真正容易被忽略的是：DOM 结构问题往往不会报错，但会在首屏渲染、辅助设备支持、SEO 排名上持续掉分——它不抛异常，只悄悄拖慢一切。
