语义正确的导航必须用包裹，而非；多导航可用多个但不可嵌套；css推荐flex布局；下拉菜单需aria-expanded和键盘支持；汉堡菜单须用aria-controls关联面板。
用 <nav></nav> 包裹才是语义正确的起点
浏览器和读屏工具靠 html 语义识别导航区域，<nav></nav> 不是可选装饰，是结构基础。不用它，CSS 再漂亮，对无障碍和 seo 都是硬伤。
常见错误：直接用 <div class="nav"> 起手，后续加 ARIA 标签补救——不如一开始就用 <code><nav></nav>。
- 必须包裹所有主导航链接，不包括面包屑、页脚链接或侧边栏次要导航
- 一个页面可以有多个
<nav></nav>（比如顶部主菜单 + 移动端汉堡菜单），但每个都应有明确作用 - 不要嵌套
<nav></nav>，子菜单用<ul>/<li> </ul>即可
CSS 实现横向排列时，display: flex 比 Float 更可靠
float 会触发 BFC、需要清除浮动、在响应式断点里容易错位；display: flex 天然支持对齐、等宽、换行控制，现代项目没理由倒退。
典型问题：导航项在小屏上挤成一行溢出容器，或者居中失效。
立即学习“前端免费学习笔记（深入）”；
- 给
<nav></nav>的直接子容器（如<ul></ul>）设display: flex，不是给<nav></nav>自身 - 用
justify-content: center居中，别依赖text-align: center+inline-block，后者在字体渲染差异下易偏移 - 加
flex-wrap: wrap应对窄屏，配合@media控制子项flex-basis，比单纯隐藏更友好
下拉菜单必须处理键盘焦点与 aria-expanded
鼠标悬停能展开，但键盘用户按 Tab 进入菜单后，没 aria-expanded 和焦点管理，等于功能残缺。这不是“增强”，是可用性底线。
错误现象：屏幕阅读器读不出“菜单已展开”，或按 Enter 无法触发子菜单，或焦点卡死在父项。
- 父级
<a></a>或<button></button>必须带aria-haspopup="menu"和动态更新的aria-expanded="true/false" - 子菜单
<ul></ul>加role="menu"，子项<li>里的链接加role="menuitem" - 用 JavaScript 监听
keydown（方向键、Esc），不是只绑click和mouseenter
移动端汉堡按钮的 aria-controls 不能漏
点击汉堡图标展开导航面板，如果没把图标和面板用 aria-controls 关联，屏幕阅读器根本不知道二者关系，用户会以为点了没反应。
兼容性坑：safari + VoiceOver 对 aria-controls 支持较好，但旧版 android TalkBack 可能忽略，所以仍需用 aria-hidden 控制面板显隐，而非仅靠 CSS display: none。
- 汉堡按钮加
aria-controls="nav-panel-id"，对应面板加id="nav-panel-id" - 面板初始状态设
aria-hidden="true"，展开时改为"false"，同时用inert属性或tabindex="-1"阻止焦点穿透 - 避免用
visibility: hidden隐藏面板——它仍占据布局空间且可被聚焦
真正难的不是做出能点的导航条，而是让每一次 Tab、每一声屏幕朗读、每一种缩放比例下，它都保持可操作、可理解、不意外。这些细节堆起来，才叫“能用”。