用对语义标签比“多用”更重要：语义标签是浏览器、搜索引擎和屏幕阅读器理解内容的依据，错用（如<section>当<div>用、<article>包裹非独立内容）或滥用（<main>重复、标题跳级、<img>缺alt）会破坏结构解析、损害可访问性与SEO，须严格遵循主题独立性、嵌套规则及工具校验。
用对语义标签比“多用”更重要
很多开发者一上来就堆 <header>、<nav>、<main>，结果发现结构更乱了——问题不在没用，而在错用或滥用。语义标签不是装饰，是浏览器、搜索引擎和屏幕阅读器理解内容的依据。
常见错误现象：
- 把
<section>当<div>用，里面只包一个<p>或按钮 -
<article>套着整个用户列表，但每条记录本身才是独立可分发的内容单元 -
<nav>里塞搜索框、登录入口等非导航功能项
实操建议：
-
<main>必须且只能出现一次，且不能嵌套在<article>、<aside>或<nav>内 -
<section>需有明确主题，并自带标题（<h2>–<h6>），否则优先考虑<div> -
<aside>应与主内容存在关联性（如博客侧边栏的“相关文章”），纯广告位或无关推荐不适用
标题层级断层会直接破坏结构解析
跳级使用标题（比如从 <h1> 直接到 <h4>）不是样式问题，而是语义断裂。浏览器和辅助技术依赖层级建立内容索引，断层会让 <h4> 被误判为新章节起点，甚至被跳过。
立即学习“前端免费学习笔记（深入）”；
使用场景：
- 单页应用中动态渲染内容时，JS 插入的标题常忽略已有层级上下文
- CMS 输出模板未约束标题深度，导致文章正文内
<h3>下突然出现<h1>
实操建议：
- 用浏览器 DevTools 的「Accessibility」面板检查「Heading level」是否连续
- 服务端或构建时加校验规则：例如用
remark-lint+remark-lint-heading-increment检查 Markdown 渲染出的 HTML - 避免用 CSS 改变视觉大小来“伪装”标题层级，
<h2>就是<h2>，别为了样式降级成<div class="h2">
alt 属性和 label 关联不是可选项
<img> 缺 alt、<input> 不配 <label for="id">，会导致页面在无图模式、弱网环境或屏幕阅读器下大面积不可用——这不是“体验降级”，是功能缺失。
容易踩的坑：
-
alt=""用于纯装饰图是对的，但把带信息的图标（如“下载 PDF”按钮里的 PDF 图标）也设为空，等于删掉了操作提示 - 用
aria-label替代<label>绑定，但没同步处理焦点管理，键盘用户 Tab 到输入框时仍无法获知用途 - 动态生成表单时，JS 创建的
<input>没补id，导致<label for="xxx">失效
实操建议：
- 所有
<img>必须有alt；若图含文字（如信息图），alt需描述文字内容，而非“图片” -
<label>和<input>必须通过for/id或嵌套关系显式关联，不能仅靠视觉位置靠近 - 用 axe 浏览器插件一键扫描
img[alt]和label[for]缺失项，比人工检查快得多
验证工具不是摆设，要嵌入开发流程
W3C Validator 能立刻暴露 <main> 重复、<h2> 缺失、<table> 无 <caption> 等硬性语义错误。但很多人只在上线前跑一次，错过修复成本最低的阶段。
性能与兼容性影响：
- 语义错误不会让页面“白屏”，但会降低 Lighthouse 的 Accessibility 分数，间接影响 SEO 权重
- 部分旧版读屏软件（如 JAWS 2020）对
<section>的处理依赖严格闭合，自闭合写法<section />会被忽略
实操建议：
- 在 CI 流程中加入
html-validate，配置规则如"html-validate:recommended"，PR 提交即报错 - VS Code 安装 “HTMLHint” 插件，实时标红
<img>无alt、标题跳级等高频问题 - 不要依赖“看起来正常”——打开 Chrome 的「Inspect → Accessibility → Landmarks」，看
<nav>、<main>是否被正确识别
语义化最易被忽略的点，是它不提供即时反馈。改完一个 <div> 成 <article>，页面外观毫无变化，但搜索引擎可能下周就开始调整索引权重，视障用户第一次访问就能顺畅操作——这些效果不会出现在控制台里，得靠工具和习惯去守住底线。
