<nav>标签非强制但至关重要，它为屏幕阅读器、键盘导航和搜索引擎提供导航区域语义；滥用或缺失会导致无障碍问题，如Tab跳过导航、NVDA无法识别、Lighthouse报错。
nav 标签不是必须的，但不用它反而容易出 accessibility 问题
HTML 里写导航栏，很多人直接用 <div class="nav"> 包一堆 <a>，看着能点、样式也对，就以为完事了。其实屏幕阅读器、键盘导航、搜索引擎都靠语义标签识别“这是导航区”，<nav> 就是干这个的——不是装饰，是功能必需。
常见错误现象：Tab 键跳过整个导航区、NVDA 读不出“导航栏”、Lighthouse 报 Navigation landmark not present。
- 每个页面最多 2–3 个
<nav>（比如主站导航 + 侧边工具栏 + 页脚链接组），别见链接就包 - 如果导航只是单个链接（如“返回首页”按钮），不用
<nav>，语义过重 -
<nav>内部不要嵌套另一个<nav>，嵌套会混淆辅助技术的层级判断
aria-label 和 aria-labelledby 怎么选？
多个 <nav> 共存时，光靠标签名不够区分，得靠 ARIA 补充说明。否则屏幕阅读器可能只说“导航”，用户不知道是顶部菜单还是面包屑。
使用场景：多语言站点、后台系统里有顶部主导航 + 左侧二级菜单 + 右上角用户操作栏。
立即学习“前端免费学习笔记（深入）”；
- 用
aria-label="主导航"适合简单命名，内容直接写死在属性里 - 用
aria-labelledby="nav-title"适合需要翻译或动态更新的场景，对应一个不可见但可被读取的<h2 id="nav-title">管理面板导航</h2> - 别同时写两个，ARIA 会优先读
aria-labelledby，aria-label被忽略
nav 里面该放什么？别塞搜索框或登录表单
<nav> 的语义边界很明确：只包含**以导航为目的的链接集合**。搜索、登录、语言切换开关这些，哪怕视觉上挨着导航栏，也不属于它。
常见错误现象：键盘用户按 Shift+Tab 想退回导航，结果卡在搜索框里；自动化测试报 Landmark contains non-navigation content。
- 搜索框归
<search>，登录表单归<form>，语言切换用<section aria-label="语言选择"> - 如果导航栏右侧有个“切换主题”按钮，它不是导航链接，不该放进
<nav> - 面包屑（Breadcrumbs）可以放
<nav>，但要加aria-label="当前位置"明确意图
CSS 布局没变，但 nav 一加进去样式乱了？
<nav> 默认是块级元素，和 <div> 行为一致，但某些老项目 CSS 里写了 div { display: flex } 这种全局规则，会导致所有 <div> 变成 flex 容器——而 <nav> 不受影响，于是视觉错位。
性能影响不大，但兼容性隐患在 IE11 或某些邮件客户端里更明显（它们对新语义标签支持弱，可能回退为 display: inline）。
- 检查是否用了通配符重置，比如
* { display: block }，这会让<nav>在旧环境表现异常 - 稳妥做法：显式写
nav { display: block }或nav { display: flex }，别依赖默认 - 用
display: contents时注意：它会让<nav>失去语义容器作用，辅助技术可能直接忽略整块区域
nav 标签本身不难，难的是它暴露了原有结构里那些“看起来能用，其实漏掉语义”的地方——尤其是当团队习惯用 class 名代替语义标签时，补 <nav> 往往只是第一步。
