nav标签是唯一被所有读屏软件识别为“导航区域”的语义标签，决定键盘跳转、屏幕阅读器播报及SEO索引；必须包裹真实href链接、用aria-label区分多导航、禁用嵌套与非导航元素，否则功能失效。
不是为了“看起来更规范”，而是因为 nav 标签直接决定了键盘用户能不能跳过它、屏幕阅读器会不会把它读成“导航栏”、搜索引擎知不知道这是全站跳转主干——不用它，div 写得再漂亮，这些功能就默认关闭。
nav 是唯一被所有读屏软件一致识别为“导航区域”的语义标签
浏览器和辅助技术（如 NVDA、VoiceOver）靠 HTML 标签判断内容意图。nav 是 HTML5 明确指定的“导航地标（landmark）”，读屏器会播报“导航栏”，并支持快捷键（如 NVDA + N）直接跳转；而 div class="nav" 在可访问性检测工具（如 Lighthouse）里会报 Navigation landmark not present，键盘 Tab 顺序也可能被忽略或错乱。
- 实操验证：用 Chrome DevTools 的“Accessibility”面板检查，
nav节点下会显示role="navigation"；div不会自动获得该 role - 真实错误现象：Tab 键跳过整个菜单、盲人用户反复按方向键却进不了导航区
- SEO 影响：Google 会用 landmarks 理解页面结构权重，主导航区缺失语义可能弱化核心页面索引优先级
多个导航区必须各自独立用 nav，不能共用或嵌套
页头主导航、侧边分类、页脚快捷链接，这三类都满足“全局性、重复性、主要跳转路径”条件，就必须各自套一层 nav，且每个都要配 aria-label。
- 正确写法：
<nav aria-label="主导航">...</nav>+<nav aria-label="页脚快捷链接">...</nav> - 错误写法：
<nav><nav>...</nav></nav>（嵌套无效，ARIA 层级断裂） - 错误写法：
<nav aria-label="主导航">...<form>搜索框</form></nav>（form不属于导航逻辑，应移出nav）
nav 本身不控制样式或行为，但影响 CSS 选择器与 ARIA 实现
nav 是语义容器，不是布局工具。但它决定了你后续怎么写 CSS 和 ARIA —— 尤其是下拉菜单这类交互组件。
立即学习“前端免费学习笔记（深入）”；
- 二级菜单必须用嵌套
ul，且必须是li的直接子元素：<li><a>产品</a><ul><li><a>云服务</a></li></ul></li>；写成<li><div><ul>...</ul></div></li>会导致:hover ul失效，且 ARIAaria-haspopup/aria-expanded关联失败 - Flexbox 布局建议直接作用于
nav ul，而不是nav > div—— 因为语义结构要求内部必须是列表 - 单页应用中，
nav a的href应设为#或空值，避免整页重载；写href="about.html"会破坏 Vue Router/React Router 状态
nav 不是装饰，是功能开关，漏掉就等于关掉了可访问性入口
最常被忽略的点：一个页面里有面包屑、主导航、页脚链接三组，但只给主导航加了 nav，其他两组用 div 包着——这会让屏幕阅读器把面包屑当成普通段落读，把页脚链接当成杂项内容跳过。每个符合“主要跳转路径”定义的链接集合，都必须拥有自己的 nav 和明确的 aria-label，哪怕它只包含两个链接。
