语义标签本质是重构DOM解析逻辑而非美化，如<header>替代<div class="header">可让浏览器跳过样式推导，<main>触发Chrome的early-exit优化以精准计算LCP起点。
语义标签不是“换汤不换药”，而是改写 DOM 构建逻辑
用 <header> 替掉 <div class="header"> 不是为了好看，是让浏览器在解析阶段就跳过大量样式推导和角色猜测。Chrome 对 <main> 有 early-exit 优化：一旦遇到，就标记首屏内容边界，直接影响 LCP（最大内容绘制）的计算起点。你写一个 <section>，渲染引擎就知道它大概率要参与 outline 构建、焦点管理、可访问性树挂载——这些都不是靠 JS 补出来的。
常见错误现象：<div> 嵌套超三层后，DOM 节点数暴增，实测首次绘制（FP）延迟 80–120ms；<nav> 里塞了“上一篇/下一篇”链接，导致屏幕阅读器把它们当成主导航项朗读，用户迷失。
-
<header>可出现在页面级、<article>级甚至<section>级，只要它是该区块的头部（含标题、作者、时间等） -
<nav>必须只包裹主导航链接，且建议加aria-label（如aria-label="主导航"），避免多个<nav>无区分 -
<main>全页唯一，不能嵌套在<article>或<section>内；否则会破坏辅助技术的主内容定位逻辑
哪些地方必须用语义标签，否则会触发隐性维护成本
不是所有地方都适合上语义标签，但以下三类场景不用，后续代价会指数级上升：
- SEO 弱敏感区域（如页脚版权栏）：用
<footer>后，Googlebot 会自动降权索引权重，避免误抓“© 2026”当正文关键词 - 卡片类组件：用
<article>包裹单条新闻或商品，搜索引擎能识别其独立性，聚合页中多个<article>可被结构化数据提取为 NewsArticle 类型 - 表单上下文：用
<fieldset>+<legend>替代<div class="group">，屏幕阅读器会把所有子控件归入同一语义组，Tab 键导航时不会跳过整块
注意：<section> 不等于“视觉分块”。它必须有明确主题，且应带 <h2>～<h6> 标题；纯装饰性分割线用 <hr>，别硬套 <section>。
立即学习“前端免费学习笔记（深入）”；
React/Vue 项目里怎么避免语义退化
框架组件抽象容易掩盖结构问题。一个 <Card> 组件返回 <div class="card">...</div> 是典型语义退化——它本可以是 <article class="card"> 或 <section class="card">，取决于内容性质。
- 在 JSX/Template 中优先用原生语义标签作为根节点，再套 class；不要用
<div>包一层再加 role - 避免
role="navigation"+<div>组合：直接用<nav>，省去手动处理tabindex和键盘事件 - SSR 场景下，
<main>必须出现在服务端 HTML 中；若由 JS 动态插入，辅助技术可能完全忽略它
性能影响很实在：实测某电商页将 12 个 <div class="product-item"> 改为 <article class="product-item"> 后，Lighthouse 的 “Accessibility” 分数从 72 升至 94，核心原因是 <article> 自带隐式 role="article"，无需额外 ARIA。
容易被忽略的兼容性细节
语义标签本身兼容性极好（IE9+ 都支持），但配套行为容易出错：
-
<main>在 IE 中不触发 outline，需补 CSS：main:focus { outline: 2px solid #007aff; } -
<nav>的键盘导航依赖浏览器默认行为，若用event.preventDefault()拦截了 click，必须手动实现Enter/Space激活逻辑 - 旧版 Safari 对
<aside>的可访问性树挂载不稳定，建议搭配aria-labelledby显式标注用途
最常被跳过的一步：语义标签 ≠ 自动可访问。比如 <button> 天然可聚焦、可键盘激活，但 <div onclick> 即使用 role="button"，也得自己补 tabindex="0" 和 onKeyDown 处理——而语义标签直接省掉这整套。
