侧边栏内容是导航链接时应使用<nav>标签，因其明确标识主要导航入口，提升可访问性与SEO；若含非导航内容（如作者简介），须拆分为<nav>与<aside>独立包裹，禁止混用或滥用语义标签。
侧边栏内容是导航链接，该用 <nav>
如果侧边栏里放的是跳转到页面其他区域、文章目录或站内频道的链接列表，<nav> 是唯一正确的选择。它明确告诉浏览器和屏幕阅读器：“这里是主要导航入口”，辅助技术能直接提供“跳至导航”快捷键。
常见错误是把整个侧边栏容器套上 <aside>，再在里面塞 <ul> 链接——这反而削弱了语义：因为 <aside> 的本意是“可移除也不影响主内容理解”，而导航链接恰恰是核心路径，不能被视作附属。
- 一个页面可以有多个
<nav>（比如顶部主导航 + 侧边文档目录） - 避免给所有链接组都加
<nav>，仅用于用户预期会频繁使用的主导航区块 - 若侧边栏同时含导航 + 作者简介 + 相关文章推荐，应拆分为：
<nav>（仅导航）、<aside>（其余）
侧边栏是作者信息或相关推荐，该用 <aside>
<aside> 不是“视觉上在右边”的标签，而是“逻辑上不参与主线叙事”的标签。它的内容被移除后，主文章仍应完整可读。
典型适用场景包括：博客文末的作者卡片、技术文章旁的术语解释框、新闻页右侧的“延伸阅读”列表。
立即学习“前端免费学习笔记（深入）”；
- 可嵌套在
<article>内部（如某段话旁的注释），也可作为<body>直接子元素（整页右侧栏） - 禁止用
<aside>包裹主导航、广告横幅或登录入口——这些属于功能模块，不是“旁注” - CSS 实现浮动/固定布局时，不要因视觉位置反推语义；先定用途，再定标签
别用 <section> 或 <div> 替代
<section> 要求内部必须有标题（<h2>–<h6>），且表示“主题性分组”，比如教程里的“安装步骤”“配置说明”两个区块。把它当侧边栏容器，等于强行给一堆杂项内容安一个主题名，语义失真。
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
<div> 完全无语义，只应在语义化标签无法覆盖的极端场景下兜底——比如需要兼容极老浏览器且必须用 class 控制行为时。现代项目中，用 <div class="sidebar"> 就是放弃语义化底线。
- 搜索引擎不会为
<div>赋予任何结构权重 - 屏幕阅读器无法通过
<div>区分导航、侧边、主内容，用户得靠逐行听读 - 团队协作时，别人看到
<div class="sidebar">无法判断里面是导航、广告还是工具条
嵌套关系容易搞错的点
真实页面常出现多层语义嵌套，最容易出错的是 <aside> 和 <nav> 的父子关系。例如一个右侧栏包含“目录导航”和“作者简介”两块：
✅ 正确写法：<aside> 包整体，内部用 <nav> 套目录，用 <section> 套作者信息；
❌ 错误写法：用 <nav> 包整个侧边栏，或把 <aside> 塞进 <nav> 里。
根本原则就一条：每个标签只表达一种语义角色，不叠加、不混用。视觉样式由 CSS 负责，HTML 只回答“这是什么”。
