<div>套<div>因缺乏语义，导致屏幕阅读器无法识别结构、搜索引擎无法提取内容权重、开发者查询失效；必须用<header>等原生语义标签替代，确保角色明确、层级清晰、可访问性与SEO双达标。
为什么 <div> 套 <div> 会让可访问性和 SEO 变差
屏幕阅读器、搜索引擎爬虫和开发者都依赖语义化标签理解页面结构。<div> 和 <span> 是无意义的“空容器”，连续嵌套会让它们无法识别标题层级、导航区域或主内容区。比如用 <div class="header"> 替代 <header>，CSS 可能照样生效，但 aria-labelledby 关联会失效，document.querySelector('header') 也查不到。
- WCAG 要求所有交互区域有明确角色（
role），而原生语义标签自带隐式role，比如<nav>对应role="navigation" - Chrome DevTools 的「Accessibility」面板会把纯
<div>树标记为 “No landmark region”，影响自动化测试通过率 - Google Search Console 的结构化数据测试工具无法从
<div class="article">中提取Article类型，但能识别<article>
<main> 和 <section> 到底怎么选
关键看是否构成独立、可复用的内容单元。<main> 是页面唯一主体内容容器，必须且只能出现一次；<section> 是带主题的分组，必须有显式标题（<h2>–<h6>），否则语义断裂。
- 错误写法：
<section><p>一段说明文字</p></section>—— 缺少标题，应改用<div>或补上<h3>说明</h3> - 正确嵌套：
<main><article><h2>博客标题</h2><section><h3>技术细节</h3>...</section></article></main> - 不要用
<section>替代 CSS 布局容器：Flex/Grid 容器用<div>即可，加role="group"（如有必要）比硬套<section>更合理
表单控件不配 <label> 会导致什么实际问题
没绑定 for/id 或未包裹控件的 <label>，会让 VoiceOver、NVDA 等读不出字段含义，用户点击 label 也无法聚焦输入框——这不仅是体验问题，更是 WCAG 2.1 的 A 级强制要求（1.3.1）。
- 最简合规写法：
<label for="email">邮箱</label><input id="email" type="email"> - 更推荐包裹式：
<label>邮箱<input type="email" name="email"></label>（自动绑定，无需id） - 多选/单选组必须用
<fieldset>+<legend>，不能只靠<h3>模拟标题 —— 否则屏幕阅读器无法将选项归入同一逻辑组
如何快速验证语义化是否达标
别等上线后被审计打回。本地开发阶段就该跑三类检查：
立即学习“前端免费学习笔记（深入）”；
- 浏览器快捷键：
Ctrl+Shift+I→ 「Accessibility」面板 → 点击元素看「Computed Properties」里是否有正确role和name - 命令行扫描：
npx axe-core --host http://localhost:3000（需运行本地服务），它会报出<div role="button">缺失tabindex或键盘事件等深层问题 - 手动 tab 导航测试：关闭鼠标，纯键盘操作，确认焦点顺序符合视觉流，所有可交互元素都能被抵达且有清晰视觉反馈
语义化不是加几个新标签就完事，而是让每个标签承担它本该承担的职责。最容易被忽略的是：动态插入的 DOM（比如 JS 渲染的评论列表）如果仍用 <div> 包裹，即使静态 HTML 写对了，也等于没做。
