W3C Validator 是最权威的 HTML 语义化检测工具，可识别 <main> 多次出现、<header> 位置错误、<article> 缺 <h1> 等问题；Warning 多为语义违规，需重点处理。
用 W3C Validator 直接验证 HTML 结构
W3C Markup Validation Service 是最权威、零配置的语义化检测入口，它不只查闭合错误，还会标记 <main> 多次出现、<header> 用在非节首位置、<article> 缺少 <h1> 等语义违规。验证结果里带 “Warning” 的条目，90% 都是语义问题，不是可忽略的提示。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 本地文件验证：把 HTML 拖进 validator.w3.org/nu/（推荐 nu 版本，对 HTML5 语义检查更严格）
- 线上页面验证：直接填 URL，适合 CI 流程中做预发布检查
- 注意看 Warning 中的 “Element X is not allowed as child of element Y” 类错误，比如
<nav>套在<footer>里，就是结构越界
Chrome DevTools 里快速定位语义缺失区块
浏览器原生工具能实时反映语义标签是否被正确识别——尤其是屏幕阅读器依赖的 ARIA role 映射关系。如果一个 <section> 在 Elements 面板里没被识别为 role="region"，大概率是缺少 aria-labelledby 或标题层级断裂。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 右键 → “Inspect” 打开 Elements 面板，选中任意语义标签（如
<article>），右侧 “Accessibility” 标签页查看 role 和 name 是否合理 - 用
Ctrl+Shift+P（Win）或Cmd+Shift+P（Mac）打开命令菜单，输入 “Accessibility” 启用“无障碍树”视图，直观看到语义层级是否扁平或断裂 - 特别注意
<main>必须有且仅有一个；若 DevTools 显示多个role="main"，说明重复使用或嵌套错误
用 axe-browser 插件批量扫描语义隐患
axe 是专为无障碍与语义合规设计的轻量插件，比 W3C Validator 更贴近真实用户场景——它会报出“<nav> 内部没有链接”“<figure> 缺 <figcaption>”这类逻辑性语义缺陷，而不仅是语法合规。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 安装 Chrome 插件 axe DevTools，点击图标后运行扫描，重点关注 “semantics” 类别下的 issue
- 典型误用会被标为严重（critical）：比如用
<div class="header">替代<header>，axe 会明确提示 “ARIA widget role not used on element with semantic tag” - 对 CMS 输出的 HTML 尤其有用：能快速发现模板层漏掉的
<h2>或错配的<aside>范围
手写检查清单：5 个高频语义断裂点
自动化工具可能漏掉上下文判断，比如 <section> 是否真有独立主题，或 <aside> 是否真的“辅助”。这时候需要人工过一遍核心逻辑。
重点核对以下 5 处（按出现频率排序）：
-
<main>是否包裹了真正不可替代的主体内容？有没有把导航或页脚意外包进去 -
<article>是否具备自包含性？能否单独 RSS 订阅或被搜索引擎作为独立结果返回 -
<nav>是否只用于主要导航路径？面包屑、页内锚点、页脚链接都不该放这里 -
<figure>和<figcaption>是否成对出现？图片无说明时，宁可用<img alt="...">也不硬套<figure> - 标题层级是否断裂？
<h1>后直接<h3>会破坏语义流，影响屏幕阅读器跳转逻辑
语义化不是贴标签比赛，而是持续校准“机器怎么读”和“人怎么想”的过程。最常被忽略的是：同一个页面里 <header> 可以出现多次（比如每个 <article> 都能有自己的 <header>），但 <main> 绝对只能有一个——这个约束在多数检查工具里不会高亮，得靠人盯住。
