nav标签用于标识站点级全局导航区域，必须包裹稳定、意图明确的跨页跳转链接，配合ul/li结构、aria-label及有效href才能实现真正可访问的导航。
nav 标签不是“做导航”的工具，而是告诉浏览器、屏幕阅读器和搜索引擎：“这一块是用户在站内移动的核心路径”。没这个语义，页面照样能跳转；加了它，才真正让导航可被识别、可被跳过、可被索引。
什么时候必须用 nav？看链接是否承担“全局跳转”功能
它只适用于那些用户在多个页面间反复使用、位置稳定、意图明确的链接集合：
- 页眉顶部横向菜单：
首页、产品、文档、博客 - 左侧垂直目录（如技术文档站的章节大纲）
- 页脚中的一级栏目入口：
服务条款、隐私政策、联系我们（前提是这些是站点级入口，不是“友情链接”或社交媒体图标） - 面包屑导航可单独用
nav包裹，但必须加aria-label="当前位置"或用aria-labelledby关联标题
如果链接只在当前页内起作用（比如“回到顶部”按钮）、或只是内容补充（如“热门标签”“相关文章”），就别硬塞进去——nav 不是收纳盒。
为什么不能直接写 nav 里一堆 a？结构和可访问性会断掉
虽然语法上允许 <nav>@#@#@#@#@#@#@#@#@#@0@#@#@#@#@#@#@#@#@#@1</nav>，但这会让键盘 Tab 顺序混乱、屏幕阅读器无法识别“这是一组导航项”，也失去列表语义带来的自动朗读提示（如“列表，共3项”）。
- 推荐结构：用
ul+li包裹链接，这是事实标准，不是“可选美化” - 必须配
aria-label，哪怕只有一个nav。不写的话，屏幕阅读器只会说“导航”，用户不知道这是主菜单还是页脚资源 - 禁用
button或javascript:void(0)链接。辅助技术不认伪链接，nav里必须有真实href
单页应用（SPA）里 nav 容易失效的两个关键点
React/Vue 项目常把菜单数据异步加载，导致初始 DOM 中 nav 是空的或只有 loading 占位符。这时候屏幕阅读器根本不会把它当导航区处理。
- DOM 加载完成时，
nav内部必须已存在至少一个带有效href的a节点。可用document.querySelector('nav a')在控制台验证 - 动态渲染菜单时，不要等接口返回才挂载
nav；先预置静态链接（如@#@#@#@#@#@#@#@#@#@0），再用 JS 替换其余项 - 响应式折叠菜单中，仅靠
display: none隐藏nav不够。要同步更新aria-expanded和aria-hidden，否则键盘用户可能卡在不可见区域
最常被忽略的不是“要不要用 nav”，而是“用了之后是否真被识别”。一个没加 aria-label 的 nav，和一个内部全是 button 的 nav，对真实用户来说，等于没写。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
