语义标签是浏览器、搜索引擎和屏幕阅读器识别内容的关键，错误使用会导致内容被忽略、无障碍失效和seo降权；必须按规范使用（仅一次）、、（需标题）、（至少两个链接）等，而非替代div。
<header></header> 不是装饰，<nav></nav> 不是占位符，<main></main> 更不是“另一个 <div>”——它们是浏览器、搜索引擎和屏幕阅读器真正能“听懂”的指令。用错或不用，代价不是样式难看，而是内容被忽略、用户被绕过、SEO权重被稀释。
<h3>语义标签直接决定机器能否识别你的内容主体</h3>
<p>搜索引擎爬虫不渲染 CSS，也不执行 JS，它只解析 DOM 结构。当你写 <code><div class="article"> 时，爬虫看到的只是一个无意义的容器；而换成 <code><article></article>，它立刻知道这是可独立索引、可被 RSS 抓取、可被结构化数据工具提取的完整内容单元。
常见错误现象：
- 页面有多个
<h1></h1>却没用<article></article>包裹每篇博客 → 爬虫无法区分主文与侧边推荐 - 导航栏用
<div id="menu"> → 屏幕阅读器用户按 “跳转到导航” 快捷键失效 <li> <code><footer></footer>里塞了广告横幅 → 辅助技术误判为版权信息，影响语义可信度 - 整页只有一个主体内容？→ 用
<main></main> - 卡片组件、文章列表项、弹窗内容？→ 用
<article></article>或<section></section>，别碰<main></main> - SSR 页面中动态插入子模块？→ 确保父模板已声明
<main></main>，子模块只提供语义子结构 - IE11 不原生支持
<section></section>语义（需 polyfill），但更重要的是：即使加了 polyfill，屏幕阅读器对它的理解仍弱于<article></article>或<nav></nav> - 某些 CMS 导出 HTML 时自动把每个 WYSIWYG 段落包成
<section></section>→ 实际语义断裂，应后置清理脚本过滤无标题的<section></section>
<main></main> 只能出现一次，但很多人在组件库中重复用了
<main></main> 表示整个页面独一无二的核心内容区域，W3C 明确要求每个文档最多一个。可一旦用 Web Components 或 SSR 框架（如 Next.js、Nuxt）做嵌套布局，很容易在子组件里也塞一个 <main></main> —— 浏览器不会报错，但会静默降级处理，部分辅助技术可能直接跳过后续语义区块。
使用场景判断要点：
误把 <section></section> 当 <div> 用，反而破坏结构清晰度
<p><code><section></section> 要求具备主题性：必须有标题（<h2></h2>–<h6></h6>），且该区块内容围绕同一主题展开。纯样式分隔、无逻辑聚合的“空白包裹层”，用 <div> 更诚实。
<p>性能与兼容性影响：</p>
<ul>
<li>过度使用 <code><section></section> 会导致 DOM 层级膨胀，Chrome DevTools 的“Accessibility”面板中语义树变臃肿，调试效率下降
无障碍不是“加个 aria-label 就完事”，语义标签才是底层支撑
很多开发者以为给 <div onclick="goHome()"> 加个 <code>role="button" aria-label="首页" 就够了。但真实场景中，视障用户依赖的是原生语义触发行为模式：比如双击 <button></button> 才会激活，而 <div role="button"> 需额外监听空格/回车键，稍有疏漏就不可操作。
<p>容易被忽略的关键点：</p>
<ul>
<li>
<code><nav></nav> 必须包含至少两个可跳转链接，否则会被读作普通容器
<time datetime="2026-08-25"></time> 中的 datetime 属性不可省略，否则屏幕阅读器无法解析为时间值<aside></aside> 内容必须与邻近 <article></article> 或 <section></section> 存在逻辑关联，孤立的广告位不应强行套用<header></header> 替代 <div class="top-bar">，你就已经把代码从“给人看”转向“给机器读”——而后者，正在成为现代 Web 的默认读者。</div>
