nav标签专用于页面主要全局导航，如页眉菜单、侧边栏目录、页脚核心链接及面包屑；必须嵌套ul/li结构并配aria-label明确标识，禁用在锚点、评论区等非主导航场景。
nav 标签不是用来“分段导航”的装饰容器，而是专用于包裹**页面中主要的、全局性的导航链接集合**。用错地方反而会破坏语义，让屏幕阅读器困惑、SEO效果打折。
nav 标签只该用在哪些位置
它对应的是用户一眼就能识别出的“主干导航”，比如：
- 页眉顶部横向菜单（
首页 / 产品 / 关于 / 联系） - 侧边栏一级目录（如文档站的左侧大纲）
- 页脚中的核心栏目链接（
服务条款 / 隐私政策 / 合作伙伴），前提是这些是站点级入口，而非次要链接 - 面包屑导航（
首页 > 分类 > 文章），可单独套一层nav并加aria-label="面包屑导航"
别把它塞进文章内锚点列表、评论区跳转链接、或“回到顶部”按钮里——那些该用 div 或普通 a。
ul + li 是 nav 内部唯一推荐的结构
直接在 nav 里写一堆 a 标签，看似省事，实则丢掉三样东西：语义层级、键盘 Tab 顺序控制、以及屏幕阅读器对“这是个列表”的识别。
正确写法必须嵌套 ul 和 li：
<nav aria-label="主导航"><ul>
<li><a href="/">首页</a></li>
<li><a href="/products">产品</a></li>
<li><a href="/about">关于</a></li>
</ul></nav>
这样做的实际好处：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
-
ul自带隐式role="list"，读屏软件会报“列表，3项” -
li是天然的焦点容器，Tab 键能按顺序进入每个a，不会跳过或乱序 - 多级下拉时，子菜单只需在对应
li内再套ul，结构自然嵌套
aria-label 是 nav 的强制配套项
没有 aria-label 的 nav，等于告诉屏幕阅读器：“这里有个导航，但我不知道它叫啥”。尤其当页面有多个 nav（比如顶部+页脚），不加标识就会混淆。
写法很简单，但必须具体：
- ✅
<nav aria-label="主导航"></nav> - ✅
<nav aria-label="页脚快速链接"></nav> - ❌
<nav aria-label="导航"></nav>（太模糊） - ❌
<nav></nav>（完全没 label）
如果导航文字本身已足够说明用途（比如“主导航”出现在视觉标题旁），也可用 aria-labelledby 指向那个标题元素，但 aria-label 更直接可靠。
响应式折叠时 nav 本身不能消失
很多人做移动端汉堡菜单，一收起就把整个 nav 设为 display: none。这会导致屏幕阅读器彻底“看不见”导航，键盘用户也无法 Tab 进去。
正确做法是保持 nav 始终在 DOM 中，仅用 visibility: hidden 或 clip-path 隐藏视觉呈现，同时确保：
- 折叠状态下的菜单仍可通过
aria-expanded="false"显式声明 - 展开按钮有
aria-controls指向对应nav的 id - JavaScript 切换时同步更新
aria-expanded和焦点管理（比如展开后自动 focus 第一个a）
语义结构一旦写进 HTML，就不能靠 CSS 或 JS “藏起来”了——它得一直可访问。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
