html嵌套深度超6层会显著拖慢低端安卓机fcp（延迟超200ms），chrome devtools中右键dom节点查看depth值可准确验证，ssr框架易无意加深层级，应优先用等语义标签替代冗余div以控制深度。
HTML代码质量不是“写得对不对”的问题，而是“跑得稳不稳、快不快、改不改得动”的综合结果。单靠W3C验证器通过，不代表它在真实设备上不会卡顿、不会报错、不会让新同事摸不着头脑。
怎么快速查嵌套深度是否超标
平均嵌套超过6层，在低端安卓机上首屏渲染（FCP）可能延迟超200ms——这不是理论值，是实测瓶颈。Chrome DevTools里右键任意DOM节点 → Show DOM properties，直接看depth字段最准。
- 别信“我只写了4层div”，SSR框架（如Next.js/Nuxt）或组件库可能在你不知情时自动包裹多层容器
-
main、section、article这类语义标签本身不减少嵌套，但能帮你一眼识别哪些容器纯属冗余 - 用Lighthouse的“Avoid excessive DOM size”建议当辅助，但它只报总节点数，不反映深度分布
HTMLHint规则怎么配才不形同虚设
默认规则集对团队几乎无用：它会报<div class="btn">没用<code><button></button>，但不会拦住document.getElementById("modal")在SSR里直接执行导致ReferenceError。
- 必开规则：
attr-no-duplication、attr-req-value、id-unique——这三条堵住90%运行时DOM操作失败根源 - 慎用
head-script-disabled：现代框架常需内联初始化脚本，硬禁会导致构建失败 - 把
attr-hyphen设为warning而非error：data-testid这种测试专用属性，没必要为命名风格阻断CI
为什么DevTools Console报错比HTMLHint更关键
HTMLHint只能检查静态结构，而真实崩溃往往来自“结构没错，但时机错了”。比如querySelector在DOMContentLoaded前执行，或SSR模板里漏了typeof window !== 'undefined'保护。
- 刷新页面后紧盯Console，重点抓两类错误：
ReferenceError（变量未定义）、TypeError: Cannot read property 'xxx' of null（DOM节点不存在） - 检查所有内联
<script></script>块：没加defer或没包DOMContentLoaded监听的，基本就是隐患点 - SSR场景下，任何含
window、document、localStorage的JS逻辑，必须显式判断环境，否则服务端直出就崩
语义标签不是为了“好看”，是为了绕过解析陷阱
用<nav></nav>替代<div class="nav">，浏览器并不会因此提速1ms；但当你给<code><nav></nav>加fetchpriority="high"，它就能比普通<div>更早触发子资源加载——这才是语义的真实价值。
<ul>
<li>
<code><main></main>必须有且仅有一个，否则fetchpriority和loading="eager"可能被浏览器忽略
<img>没alt不是SEO问题，是可访问性灾难；但alt=""又没加role="presentation"，读屏器会跳过还是误读，取决于具体引擎h1–h6）错乱不影响渲染，但会让Lighthouse的“structured data”检测直接挂零分真正难的不是写合规HTML，而是判断哪条规则该严格执行、哪条该为实际运行让路。比如id-unique必须死守，但attr-lowercase在团队已用驼峰命名约定时，强行转小写反而增加维护成本。
