必须用于有独立主题且带标题（–）的内容区块，否则语义失效；是无语义纯容器，专用于样式、脚本或布局分组，二者不可混用。
直接说结论：语义化不是加几个 <header></header> 标签就完事，关键在元素与内容意图是否真正匹配——用错标签比不用更伤可访问性和SEO。
什么时候该用 <section></section> 而不是 <div>
<p><code><section></section> 表示一个有独立主题、可被大纲工具（如屏幕阅读器、浏览器大纲视图）识别的“章节”，必须自带标题（<h1>–<h6></h6>
</h1>），否则它和 <div> 没本质区别，甚至更糟。
<ul>
<li>✅ 正确：产品列表页中每个品类区块带 <code><h2>智能手表</h2>，外层用 <section></section>
<div> 更诚实
<li>⚠️ 注意：<code><section></section> 嵌套过深（如三层以上）会破坏大纲层级，优先考虑用 <article></article> 或重构内容结构
<article></article> 和 <aside></aside> 的边界在哪
<article></article> 是能独立分发、复用的内容单元（博客正文、新闻稿、用户评论）；<aside></aside> 是与当前内容相关但非核心的补充信息，脱离上下文仍可理解，但不能独立存在。
- ✅
<article></article>：一篇独立发布的技术笔记，URL 可被 RSS 抓取，有自己发布时间和作者 - ✅
<aside></aside>：侧边栏里的“本文相关术语解释”或“作者简介卡片”，放在文章内部或页面侧边均可 - ❌ 把整页导航栏塞进
<aside></aside>—— 它是全局功能，不属于当前内容的“补充”，应保持为<nav></nav> - ⚠️ 性能提示：搜索引擎对
<article></article>内容权重更高，但滥用（比如每个商品卡片都套一层<article></article>）可能稀释主内容信号
表单控件必须配 <label></label>，且 for 和 id 要严格一致
这是语义化里最容易被跳过的硬性要求。不配 <label></label>，屏幕阅读器无法关联控件，触摸设备点击区域也变小，直接影响 WCAG 合规性。
- ✅ 推荐写法：
<label for="email">邮箱地址</label><input type="email" id="email"> - ✅ 更简洁写法（隐式绑定）：
<label>邮箱地址<input type="email"></label>—— 但注意：嵌套内不能有其他块级元素 - ❌ 常见错误：
for="email"和id="user-email"不一致，或多个控件共用同一id - ⚠️ 兼容性坑：某些旧版 iOS Safari 对
<label></label>包裹<input type="file">支持不稳定，建议额外加role="button"并监听 click
<time></time>、<address></address> 这类“小众语义标签”真有必要用吗
有必要，但得看场景。它们不提升视觉效果，但为机器解析提供明确信号——尤其在结构化数据（Schema.org）、语音助手抓取、自动化测试中起作用。
- ✅
<time datetime="2024-05-20">5月20日</time>：让日历应用识别日期，避免 “昨天”“下周三” 这类模糊表述 - ✅
<address></address>只用于最近祖先的联系信息（比如页脚公司地址），不是所有文字地址都适用；它会默认斜体，可通过 CSS 重置 - ❌ 把商品发货地写成
<address>广东省深圳市</address>—— 这是地理信息，不是联系信息，应使用<span></span>+ 微数据或itemprop - ⚠️ 工具链影响：部分 HTML 校验器（如 W3C Validator）对
<address></address>的父容器有要求（需在、<article></article>或<aside></aside>内），放错位置会报错
语义化的难点不在标签数量，而在持续判断“这段内容对谁而言是‘什么’”——是给用户看的？给屏幕阅读器听的？还是给爬虫解析的？同一个 <nav></nav> 在首页可能是主导航，在文章页可能只是“返回列表”链接组，语义权重完全不同。
