侧边栏本质是导航还是补充内容需依语义判断：纯跳转链接用nav，附属信息用aside；混合型应外层aside包裹，内部按功能分用nav、section等标签。
侧边栏是导航还是补充内容？先分清 nav 和 aside
不是所有侧边栏都该用 aside。如果侧边栏里全是跳转链接（比如“分类目录”“归档”“用户中心”），它本质是导航行为，必须用 nav；只有当内容是作者简介、延伸阅读、术语注释、引用说明等与主文相关但可独立移除的附属信息时，才适合用 aside。
常见错误：把整个侧边栏套一层 aside，结果导航链接失去语义；或反过来，用 nav 包住作者照片和联系方式，让屏幕阅读器误判为导航区域。
判断依据很简单：
– 能否删掉这部分而不影响主文逻辑？能 → aside
– 是否提供跨页面/跨章节的跳转路径？是 → nav
用 nav 写侧边栏导航时，别漏掉 aria-label
nav 标签本身不说明“这是什么导航”，屏幕阅读器只读出“导航区域”，用户不知道是主菜单、分类导航还是页内锚点。必须加 aria-label 明确用途。
示例：
<nav aria-label="文章分类导航"><br><ul> <br><li><a href="/category/frontend">前端技术</a></li> <br><li><a href="/category/backend">后端开发</a></li> <br> </ul> <br></nav>
注意：
– 不要用 aria-label="侧边栏" 这种无效描述
– 当前选中项建议加 aria-current="page"
– 避免嵌套多个 nav（如一个大 nav 套里面另一个 nav），除非语义确实分层（如“主导航”+“文章内小节导航”）
aside 不等于“视觉侧边栏”，CSS 才决定它在哪
aside 是语义标签，浏览器不会自动把它放到右边。它默认是块级元素，会垂直堆在主内容下方——这是最常被忽略的点。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
要让它“看起来像侧边栏”，必须配合 CSS：
– 父容器用 display: flex 或 display: grid
– aside 设 flex-basis 或 grid-column
– 小屏下用 @media (max-width: 768px) 改成 display: block 防止溢出
嵌套位置影响语义范围：
– 放在 article 内部 → 仅服务该篇文章（如文末的术语解释）
– 作为 body 直接子元素 → 服务整页（如全站作者栏、标签云）
– 别塞进 header 或 footer 里，那会破坏语义边界
混合型侧边栏怎么组织结构？外层 aside + 内部按功能拆
现实中侧边栏常同时含导航和补充内容（比如左侧是分类链接，右侧是作者卡片）。这时不该硬凑进一个 nav 或一个 aside，而应外层用 aside 统一语义归属，内部再按功能分块：
<aside aria-label="页面辅助内容"><br><nav aria-label="文章分类导航">…</nav><br><section aria-labelledby="author-heading"><br><h4 id="author-heading">作者简介</h4> <br><p>张三，前端工程师…</p> <br></section><br></aside>
关键点：
– 外层 aside 的 aria-label 要概括整体作用，不是重复“侧边栏”
– 内部 nav 和 section 各自带自己的语义和可访问性属性
– 别用 div 替代 section 来包裹作者信息，否则丧失“独立内容区块”的语义
最容易被忽略的是：语义标签一旦写错，后续加再多 CSS 或 JS 也补不回可访问性损失。与其纠结“怎么让它靠右”，不如先问一句——这段内容，对主文来说，到底是路标，还是注脚？
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
