必须唯一且仅包裹核心内容，不可嵌套或滥用；用于可独立分发的内容单元，用于主题性子区域；须与主内容逻辑相关；和需规范使用以提升seo与无障碍支持。
<main></main> 必须且只能出现一次，这是判断语义化是否落地的硬指标。用错或滥用 <section></section>、<article></article> 不是细节问题，而是结构逻辑缺陷。
用对 <main></main> 才算真正理解语义层级
很多开发者把 <main></main> 当成另一个 <div> 来用，甚至在页面里塞多个 <code><main></main>，或者把它套在导航/侧边栏里。这直接破坏了辅助技术对“主内容”的识别路径。
正确做法只有一条：整个页面中 <main></main> 必须唯一，且仅包裹用户真正要阅读或交互的核心内容（比如博客正文、商品列表、表单主体），不包含 <header></header>、<nav></nav>、<aside></aside> 或 <footer></footer>。
- 如果页面有多个“主要内容区块”（如首页含轮播+推荐+最新文章），不要拆成多个
<main></main>，而应保留一个<main></main>，内部用<section></section>划分主题 -
<main></main>不能嵌套在<article></article>或<section></section>里——它必须是文档级容器 - 某些 CMS 模板会自动生成多个
<main></main>，上线前务必检查 DOM 结构
<article></article> 和 <section></section> 的边界在哪
两者都表示“内容区块”，但语义完全不同：<article></article> 是可独立分发、重用的内容单元（如一篇博客、一条新闻、一个用户评论）；<section></section> 是按主题组织的页面子区域（如“技术栈介绍”“项目亮点”“客户评价”），本身不具备独立性。
常见误用：
- 把整个“关于我们”页面包进
<article></article>——它不是可被 RSS 订阅或单独分享的单元 - 用
<section></section>替代<nav></nav>写导航菜单 —— 导航是功能型区域，不是主题分组 - 在
<article></article>内部再套<article></article>（如评论嵌套评论）——合法，但需确保每层都有明确的独立语义（例如用<article itemscope itemtype="https://schema.org/Comment"></article>）
别让 <aside></aside> 变成“不知道放哪就丢这儿”的垃圾桶
<aside></aside> 不是侧边栏 CSS 容器，而是语义上与主内容“相关但可分离”的内容。典型场景包括：文章里的术语解释框、博客页的作者简介、产品页的参数对比表。
容易踩的坑：
- 把广告位、热门文章推荐、订阅表单硬塞进
<aside></aside>—— 这些和当前主内容无逻辑关联，应改用<section></section>或普通<div> <li>在 <code><main></main>外部写<aside></aside>—— 语义失效，屏幕阅读器无法建立上下文关系 - 忽略
<aside></aside>的嵌套合理性：它可以出现在<article></article>内（如某段代码旁的说明），也可以在<section></section>内，但不宜跨多层嵌套 - 所有带日期的信息（发布、更新、事件时间）必须用
<time datetime="2026-08-25">今天</time>，而非纯文本或<span></span> -
<figure></figure>必须配<figcaption></figcaption>，哪怕只是空标签；图片、图表、代码块、引用块都适用，不只是“插图” - 避免把整段图文混排内容塞进一个
<figure></figure>—— 它代表一个逻辑单元，不是排版容器
<time></time> 和 <figure></figure> 是专业度的隐藏得分点
多数人只记得 <header></header> 和 <footer></footer>，却忽略这些轻量但高信息密度的标签。它们不改变布局，但直接影响 SEO 解析精度和 a11y 支持深度。
实操建议：
