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