语义化元素是现代html的基础设施，不使用会导致seo、无障碍和维护持续受损；搜索引擎依赖dom结构识别内容，屏幕阅读器靠语义标签导航，团队协作中语义标签保障长期可维护性。
语义化元素不是“锦上添花”，而是现代 HTML 的基础设施——不写它们，<div> 堆出来的页面在 SEO、无障碍、协作维护上会持续掉血，而且越往后越难补救。
<h3>搜索引擎怎么靠语义标签理解你的页面</h3>
<p>Google 和 Bing 不是靠 CSS 渲染结果来判断内容重要性的，它们优先解析 DOM 结构。当你用 <code><header></header> 包标题、<main></main> 包正文、<article></article> 包独立博文时，爬虫能直接定位核心内容区块，跳过广告、侧边栏等干扰信息。
反例：<div class="main-content"> 对爬虫毫无意义；<code><div id="nav"> 不如 <code><nav></nav> 明确——class 名称可能被压缩、重命名、甚至误写，而原生语义标签是强制可识别的。
- 多个
<main></main>会被视为错误，浏览器和爬虫只认第一个，其余忽略 -
<section></section>必须有标题（<h1></h1>–<h6></h6>），否则语义断裂，辅助技术可能跳过它 -
<article></article>内容应能独立分发（比如 RSS 抓取或分享到社交媒体），否则用<section></section>更准确
屏幕阅读器依赖语义标签做“结构导航”
视障用户不会“看”布局，而是用快捷键（如 Ctrl+Alt+Insert 在 NVDA 中）快速跳转到 <nav></nav>、<main></main> 或 <footer></footer>。如果全用 <div>，他们得逐行听完整页，效率暴跌。
<p>更隐蔽的问题：某些语义标签自带隐式 ARIA role。例如 <code><nav></nav> 等价于 role="navigation"，而 <main></main> 等价于 role="main"。手动加 ARIA 属性容易出错，原生语义标签则零配置、零冲突。
-
<aside></aside>必须与<main></main>同级或嵌套在<article></article>内，否则会被读作“无关上下文” -
<footer></footer>放在<article></article>内表示该文章的作者信息/发布时间；放在底部才表示整个页面版权信息 - 用
<div role="button"> 不如直接用 <code><button></button>—— 后者自带键盘焦点、空格/回车触发、禁用状态样式团队协作和长期维护的真实成本
一个
<div class="card-header"> 在 3 个月后可能被改成 <code><div class="section-title">，没人记得它原本承载的是什么逻辑。但 <code><header></header>永远是头部，<section></section>永远是逻辑区块——语义不随 CSS 类名漂移。重构时尤其明显：想把所有导航抽成组件？搜
<nav></nav>一行搞定；想批量替换页脚？<footer></footer>是唯一可靠锚点。而靠 class 名匹配，永远漏几处、改错几处。-
<section></section>和<div> 视觉效果完全一致，但前者在 DevTools 的 Accessibility 面板里会显示“Section”节点，后者只是“Generic” <li>Vue/React 中用 <code><template></template>或 JSX 写<div classname="header">，不如直接用 <code><header></header>—— 语义层不依赖框架，CSS 和 JS 都能无感适配 - 过度嵌套
<section><section><section></section></section></section>不仅冗余，还会让屏幕阅读器报出“Section Section Section”，失去导航意义
真正难的不是记住哪些标签叫什么，而是每次写 HTML 时多问一句：“这个容器在业务逻辑里扮演什么角色？”——答案决定了该用
<article></article>还是<section></section>，<aside></aside>还是<div>。漏掉这一步，后面所有优化都建立在流沙之上。</div> -
