aside标签用于主题相关但非核心的补充内容，其判断标准是移除后主文逻辑仍完整；误用包括导航、广告等全局UI；可嵌套在article或body中，但不可置于header/footer/nav内。
aside 标签不是“侧边栏容器”，它表达的是内容与主文的**主题相关但非核心**——放错地方反而破坏语义，屏幕阅读器和搜索引擎会据此降权。
什么内容适合放进 aside
判断标准只有一条：这段内容拿掉后，主文逻辑依然完整；但它能为当前上下文提供补充、背景或延伸。
- 文章中某个人名首次出现时，紧随其后的简短生平说明（不是整篇人物传记）
- 技术文档里某个术语旁的
definition解释块 - 博客正文中引用某段代码后，附带的“为什么不用
forEach”小段分析 - 新闻报道中插入的、与事件相关的地理背景图+两句话说明
注意：aside 不因物理位置在右侧就成立——即使你用 CSS 把它压到页面最底下，只要语义匹配，它仍是 aside。
哪些“侧边栏”内容不该用 aside
常见误用是把导航、广告、用户登录框、站点 logo 这类全局性 UI 塞进 aside。它们和当前页面主题无关，也不随主文变化而变化。
- 全站通用的左侧菜单 → 应该用
nav - 页脚上方的“热门标签云” → 属于站点元信息，用
section+h2更合适 - 右上角“微信扫码关注”按钮 → 是独立功能模块，建议用
section或无语义div - 文章列表页每项右侧的“发布时间+评论数” → 这是列表项的一部分，应保留在
article内部，而非抽成aside
aside 的嵌套规则和 DOM 位置影响
它可出现在 article 内部（表示仅对该文章片段起补充作用），也可放在 body 一级（表示对整页主内容起补充）。但不能作为 header、footer 或 nav 的子元素——这些元素本身已有明确语义边界。
示例：
<article>
<h2>React Server Components</h2>
<p>RSC 允许组件在服务端渲染……</p>
<aside>
<p><strong>对比：</strong>传统 CSR 中，所有组件都在浏览器解析执行。</p>
</aside>
</article>
这个 aside 语义清晰：它不定义 RSC 是什么，只是帮读者快速建立参照系。如果把它挪到 body 最外层，就会让人困惑——它到底是在补充哪一段？
真正容易被忽略的是：当多个 aside 并存时，它们之间没有隐含顺序关系。辅助技术不会自动按“左→右”或“上→下”串联朗读，所以别指望靠 DOM 顺序来组织逻辑流。需要强关联的内容，得靠文本本身说清。
