aside标签仅提供语义不控制布局，需css配合实现侧边栏效果；正确语义使用场景为附属内容，全局导航应优先用nav；现代布局推荐flexbox，移动端需注意dom顺序与视觉顺序一致。
aside 标签只负责语义，不负责布局
写了 aside，内容还在正文下面，不是标签没生效，是它本就不该“自动跑到右边”。aside 是语义容器，浏览器默认当普通块级元素处理：display: block、width: 100%、无浮动、无定位。
常见错误现象包括：aside 和 main 垂直堆叠、侧边栏背景色没区分、用 float 后父容器塌陷。这些问题根源不是 HTML 写错了，而是 CSS 没跟上。
-
aside应嵌套在article内（服务单篇内容），或与main并列作为body的直接子元素（服务全站） - 若内容与主文无逻辑附属关系（如全局导航、页脚工具栏），优先用
nav而非aside - 纯装饰性区块、广告位未标注来源时，用
div更合适，硬套aside反而误导读屏器
flexbox 是现代侧边栏布局的最小可靠方案
不用 JavaScript、不依赖浮动，仅靠两行 CSS 就能稳定控制流向和尺寸：display: flex 打底，flex: 0 0 240px 锁定侧边栏宽度。
比单纯写 width: 240px 更安全——它明确禁止缩放，避免长文本或图片撑破布局；flex: 1 给主内容区，自动占满剩余空间。
- 父容器必须设
display: flex，否则子元素的flex值完全无效 - 主内容区若含未换行 URL 或长单词，需加
min-width: 0防止溢出 - 移动端切换为垂直布局时，用
order: -1把aside提到顶部，而非display: none——后者会破坏键盘 Tab 顺序
nav 标签才是文档侧边栏的语义首选
API 文档、Markdown 编辑器的大纲栏、技术文章的快速导航锚点，本质是“服务于当前文档结构的导航辅助”，不是延伸阅读或广告——所以应优先用 nav，不是 aside。
nav + ul + li + a 是屏幕阅读器识别导航区域的最小可靠结构。中间插 div 会导致 Tab 顺序跳过整个菜单、SEO 权重降级、:focus-within 失效。
- 每个
a必须带href指向对应id，否则键盘无法跳转 - 当前激活项应通过服务端或构建时添加
aria-current="page"，别只靠 JS 动态加.active - 多个侧边栏（如系统设置菜单 + 快捷工具栏）要各自独立用
nav，并配aria-label区分
响应式断点里最容易漏掉的三件事
小屏下侧边栏没收进顶部、文字换行失效、滚动错位，往往不是媒体查询没写，而是配套规则被忽略。
- 移动端
@media (max-width: 768px)内，aside必须加width: 100%+overflow: hidden，否则 Flex 容器会撑宽父级 -
nav ul li a要设display: block，否则触控热区只有文字部分，小屏体验差 - 如果侧边栏用了
position: sticky，父容器不能设overflow: hidden，否则 iOS Safari 会截断粘性效果
aside 放在 main 前面却靠 CSS order 或 float 推到右边，键盘 Tab 仍从侧边栏开始——对屏幕阅读器用户来说，这等于先听广告再听正文。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
