嵌套过深会导致dom构建中断或截断，浏览器流式解析html时每层嵌套均需创建节点、计算样式、触发布局检查，超6层后在低端设备或弱网下易因内存压力或超时终止解析，使后续标签无法进入dom树。
嵌套过深会让DOM构建中途截断
浏览器流式解析HTML时，每层嵌套都要创建节点、计算样式、检查布局。一旦平均嵌套深度超过6层，低端安卓机或弱网环境下，解析器可能因内存压力或超时机制直接终止后续标签处理——你写的 <footer></footer> 或 <aside></aside> 根本不会进DOM树，DevTools里都看不到。
实操建议：
- 用Chrome DevTools → Elements面板右键任意节点 →
Show DOM properties查depth值，超过6必须拆解 - 避免
<div><div><div><table><tr><td><div></div></td></tr></table></div></div></div>这类结构；<td> 内嵌套会加剧样式重排风险 <li>能用 <code><section></section>、<main></main>、<article></article>替代纯<div> 堆叠的，优先替换——不减少行数，但压低实际DOM节点数（移动端稳定底线是800以内） <h3>script位置不当会让HTML“半途而废”</h3> <p>没加 <code>defer或async的<script src="app.js"></script>放在里，浏览器就得暂停HTML解析、下载并执行完脚本，才能继续建DOM树。这不是JS体积问题，1KB也能卡住首屏。实操建议：
- 非关键逻辑（统计、埋点、第三方SDK）一律加
defer，保序且不阻塞解析 - 纯交互脚本（如按钮绑定）可用
async，但注意它不保序，且可能在DOMContentLoaded前运行——若操作DOM，大概率报Cannot read property 'addEventListener' of null - 真要操作首屏DOM的脚本（轮播初始化、表单校验），放
开头；别信“DOMContentLoaded比load快”的模糊说法——实测晚100ms加载，LCP就晚100ms
内联资源过大拖慢TTFB和DOM构建起点
把大段CSS或初始化数据塞进
<style></style>或<script type="application/json"></script>，HTML体积飙到50KB+，不仅拉高TTFB（服务器响应头发出时间），还会让浏览器解析器卡在文本扫描阶段，DOM构建被迫延后。实操建议：
- 用
curl -I查响应头Content-Length，HTML体超15KB时重点检查内联资源占比 - 关键CSS外链 +
<link rel="preload" as="style">，比内联更可控；预加载能抢占带宽，避免等HTML解析到对应<link>才发起请求 - 初始化数据改用
<script type="application/ld+json"></script>或服务端注入到全局变量，避免大块JSON字符串污染HTML主体
语义缺失不报错但会在三个维度同时埋雷
结构问题最危险的地方在于它不报错：你把
<h2></h2>全改成<h3></h3>维持层级连续，或把<header></header>抽成组件导致语义断裂，代码照跑，但SEO索引、无障碍访问、首屏渲染会同步劣化。实操建议：
- 用
axe或 Lighthouse 的 Accessibility audit 检查role和 ARIA 标签是否缺失 - 标题层级必须连续（
h1→h2→h3），跳级或倒置会让屏幕阅读器和爬虫丢失内容结构 - 现代浏览器对
<nav></nav>、<main></main>等语义标签有解析优化策略，它们本身不增加开销，还能缩短DOM遍历路径
<table> 里出现 <code><div>，能不能接受把 <code><header></header>拆成无语义的组件，这些选择不触发错误，却在首屏、SEO、无障碍上同时生效——而且延迟暴露。 - 非关键逻辑（统计、埋点、第三方SDK）一律加
