aside 标签仅是语义容器，不具侧边布局功能，其核心语义是“可安全省略的弱关联补充信息”；广告、工具栏等强关联或交互性内容误用 aside 会导致无障碍、seo 和合规问题。
aside 标签根本不表示“侧边”或“工具栏”
浏览器不会给 aside 加任何布局样式：不浮动、不设宽、不靠右、不悬浮。它只是个语义容器，渲染效果和 div 完全一致。所谓“侧边栏”，纯靠 CSS（如 display: flex 或 grid）实现，与 aside 标签名无关。
更关键的是，aside 的语义核心是「与主内容存在弱逻辑关联，且可移除而不破坏主文完整性」。一旦内容本身和当前 article 或 main 毫无关系（比如全站通用的筛选控件、第三方广告 JS 插槽），那就已经违背了语义前提。
网页广告放 aside 是高风险误用
MDN 和 WCAG 明确指出：aside 表达的是“可安全省略的补充信息”。而广告模块恰恰相反——它常需强制展示、合规标注（如“广告”字样）、被爬虫识别、被监管系统审计。塞进 aside 会导致：
- 屏幕阅读器跳过该区块（因标记为
complementarylandmark，部分 AT 默认忽略） - SEO 抓取器降权或漏抓广告标识，影响广告合规性验证
- 动态加载广告时，若父容器语义错配，焦点管理（
tabindex、aria-live）极易失效
正确做法：
- 静态 banner：用 <section aria-label="广告"></section>
- 文内推广卡片：用 <div role="complementary" aria-label="推广内容">
<br>
- JS 动态广告位：直接 <code><div class="ad-slot">，靠 class 控制行为与样式<h3>侧边工具栏必须用 div + ARIA 显式声明</h3>
<p>工具栏（filter controls、sort buttons、export dropdowns）本质是交互控件集合，与主文无语义附属关系，也不满足“移除后主逻辑仍完整”的条件。强行套 <code>aside 会让屏幕阅读器读作 “complementary landmark”，用户完全无法预期这是操作入口。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
实操要点：
- 容器用
<div class="toolbar">，加 <code>role="region"和明确的aria-label（如aria-label="文章筛选工具"） - 每个可聚焦控件（
button、select）必须有tabindex="0"或原生可聚焦属性 - 若需键盘导航逻辑（如方向键切换），得手写
keydown处理，aside不提供任何辅助 - 响应式折叠时，用
aria-expanded和aria-controls同步状态，别依赖视觉位置 - 某些读屏器（如 NVDA 2025.4）对嵌套在
header或footer内的aside直接静音处理 - 微信内置浏览器、部分国产安卓 WebView 对
aside的 landmark 解析不一致，可能合并或跳过 - 当
aside被 JavaScript 动态插入到非语义上下文（如直接 append 到body顶层），其与最近article的逻辑关联就断裂了——此时它已不是“旁注”，而是“语义孤儿”
最容易被忽略的兼容性断点
很多团队在开发阶段用 Chrome + DevTools 看布局没问题，就认为语义也 OK。但真实场景中：
判断是否真该用 aside，只问一句：删掉这块 HTML，主内容还能不能独立成立、被理解、被索引？ 如果答案是否定的，那就别碰这个标签。
