html质量核心在于结构能否被机器与人快速理解，语义化标签须准确表达内容关系，grid/flexbox应支撑而非扭曲语义结构，验证警告揭示结构性矛盾而非仅格式问题。
HTML代码质量不是“写得对不对”的问题，而是“结构能不能被机器和人同时快速理解”的问题；现代布局方案（Grid/Flexbox）不是炫技工具，而是让语义化结构真正落地的支撑。
语义化标签怎么选才不踩坑
很多人把 <section></section> 当成万能容器，结果嵌套三层 <section></section> 还加了 class="wrapper" —— 这等于白用。语义标签的核心是表达内容关系，不是替代 <div> 的视觉占位符。
<ul>
<li>
<code><main></main> 必须且只能出现一次，包裹页面核心内容，不能套在 <article></article> 里再塞一个 <main></main>
<section></section> 需有明确主题和标题（<h2></h2> 或更高），纯布局分隔不用它<article></article> 表示可独立分发、复用的内容单元（如博客正文、新闻条目），不是每个卡片都算 <article></article>
<nav></nav> 只用于导航链接集合，侧边栏菜单、页脚链接列表、面包屑都算；但“返回顶部”按钮不算CSS Grid 和 Flexbox 如何反向约束 HTML 结构
布局技术一旦用错，就会倒逼 HTML 写出反模式结构。比如为了实现横向居中硬加一层 <div class="flex-center">，本质是 CSS 没写对，却污染了 HTML。
<ul><li>用 <code>display: grid 做整体页面分区时，<header></header>、<main></main>、<aside></aside> 直接作为 grid item，不再套 <div>
<li>用 <code>display: flex 排列一组按钮或标签时，父容器用 <nav></nav> 或 <footer></footer> 即可，不需要额外 <div class="btn-group">
<li>避免为适配浮动或绝对定位而添加无意义 wrapper —— Grid/Flexbox 天然支持子元素直接参与布局，HTML 层级应扁平到只剩语义骨架</li>
<h3>class 命名和 DOM 深度如何影响长期维护</h3>
<p>一个 <code>class="card__content--large" 看似规范，但如果它依赖五层嵌套才能生效，那 BEM 就成了枷锁。真正影响可维护性的不是命名格式，而是 class 与 DOM 位置的耦合强度。
- 优先用语义化标签本身做选择器：
main > article h2比.article-title更稳定，因为标题不会突然变成<p></p> - 避免深度大于 3 的 CSS 选择器（如
.sidebar .list .item a），它会迫使 HTML 必须维持固定嵌套，一改就崩 -
kebab-case是底线，但更重要的是：class 名要能脱离当前 DOM 位置仍可理解，比如search-input比top-bar-input更可持续
验证工具为什么总报“警告”却不报错
W3C Validator 或 HTMLHint 报 Element “main” not allowed as child of element “div” 这类警告，不是浏览器会挂掉，而是它暴露了结构逻辑断裂 —— 比如你在 <div class="layout"> 里包了个 <code><main></main>，等于告诉机器：“这里有个主内容区，但它从属于某个非语义容器”，这违背了语义层级的天然约束。
- 这类警告往往意味着你正在用 CSS 布局逻辑覆盖 HTML 语义逻辑，长期看会导致 JS 查询（如
document.querySelector('main')）失效或意外命中 - HTML 验证必须跑在构建后产物上，而不是开发时的模板文件 —— 因为 include、JS 动态插入可能生成非法结构
- 把验证当成 CI 步骤强制执行，比人工 review 更可靠；但别只盯“错误数”，重点看警告是否指向结构性矛盾
最常被忽略的点：语义化不是加几个新标签就完事，而是每次写 <div> 前，得先问自己——这个容器有没有独立语义？能不能被屏幕阅读器、搜索引擎或未来某段 JS 脚本无歧义地识别？答案是否定的，那就该删。</div>
