只有当链接组是站点级或应用级的主要导航区块时才应使用标签，如顶部主导航、侧边菜单、汉堡菜单等；其他如相关阅读、操作链接、面包屑（需加aria-label）等需按语义选用合适标签。
nav 标签该用在哪些地方
只有当一组链接是站点级或应用级的**主要导航区块**时，才应该用 <nav></nav>。它不是所有链接容器的“语义万金油”——比如文章内部的“上一篇/下一篇”、页脚一堆杂项链接、搜索结果页的筛选标签，都不适合套 <nav></nav>。
常见适用场景包括：
- 顶部横栏主导航（含首页、产品、关于、联系等入口）
- 侧边垂直导航菜单（如后台管理系统的功能模块列表）
- 响应式折叠后的汉堡菜单展开区域（只要内容仍是主导航）
- 同一页面内多个独立导航需求时，可配合
aria-label区分，例如：<nav aria-label="主导航"></nav>和<nav aria-label="页内章节导航"></nav>
为什么不能把所有链接都包进 nav
过度使用 <nav></nav> 会稀释语义价值，让屏幕阅读器用户难以快速定位真正重要的导航路径。浏览器和辅助技术依赖语义标签做结构推断——<nav></nav> 被默认视为“高频跳转入口集合”，如果每个 <a></a> 都塞进去，相当于告诉读屏软件“所有链接都同等重要”，反而失去指引意义。
典型误用：
- 文章末尾的“相关阅读”推荐链接块 → 应用
<section></section>或<aside></aside> - 评论区的“回复”“编辑”操作链接 → 属于交互控件，用
<div> 或带 role 的按钮更合适 <li>面包屑（Breadcrumb）→ 推荐用 <code><nav aria-label="面包屑"></nav>是可以的，但需确保它确实是导航路径而非单纯文本展示 - 把整个头部（logo + nav + 搜索框）一股脑包进一个
<nav></nav>—— logo 不是导航项，搜索框若非主导航组成部分（如仅站内检索），也不必强绑 - 用
<nav></nav>替代<header></header>—— 二者语义不同：<header></header>是内容区头部，<nav></nav>是导航行为载体
nav 里能嵌套什么？常见结构陷阱
<nav></nav> 内部通常只包含导航性内容：链接、按钮、搜索框（如果属于导航流程）、以及必要的包裹容器（如 <ul></ul>、<div>）。但它**不能直接放段落、标题或大段说明文字**。
<p>容易踩的坑：</p>
<ul>
<li>在 <code><nav></nav> 里写 <p>欢迎访问我们的网站</p> —— 这破坏了导航纯粹性，应移出
推荐结构示例：
<nav aria-label="主导航"><ul>
<li><a href="/">首页</a></li>
<li><a href="/products">产品</a></li>
<li><a href="/contact">联系</a></li>
</ul></nav>
兼容性和 SEO 影响很小，但语义错误会影响可访问性
不用 <nav></nav> 不会导致页面崩溃，也不会明显拖慢加载速度；搜索引擎对它的识别也远不如 <h1></h1> 或 <main></main> 敏感。但它直接影响屏幕阅读器用户的导航效率——比如 JAWS 或 NVDA 可通过快捷键 N 直接跳转到下一个 <nav></nav>，若语义错乱，这个功能就失效了。
所以核心判断标准只有一个：这个链接组，是否承担了“让用户在不同功能区/内容板块之间系统性移动”的作用？如果是，就用 <nav></nav>；如果只是点缀、补充或操作延伸，那就别用。
最常被忽略的一点：nav 不需要视觉样式支撑语义，但一旦用了，就要保证它内部确实没有非导航内容——哪怕是一行注释、一个空 <span></span>，都可能干扰辅助技术解析。
