nav的作用是明确标识页面核心导航区域，使浏览器、搜索引擎和屏幕阅读器能准确识别并高效处理；必须包含真实跳转链接，配合aria-label区分多导航区，禁止滥用或混入非导航内容。
nav 的作用不是“加个标签好看一点”，而是明确告诉浏览器、搜索引擎和屏幕阅读器：“这一块是页面的核心导航区域”。不加 nav，链接照样能点；但加了，才能让辅助技术快速跳转、SEO 更准确识别导航权重、代码结构更易维护。
为什么必须用 nav 而不是 div
语义错误会导致实际问题：
- 屏幕阅读器默认忽略纯 div 包裹的链接列表，用户得逐个 tab 才能摸到导航项
- 搜索引擎可能弱化该区域链接的权威性，影响“关于我们”“服务”等页的收录优先级
- 多个导航共存时（比如顶部主菜单 + 页脚快捷入口），只有 nav 支持用 aria-label 区分，例如：<nav aria-label="主导航"></nav> 和 <nav aria-label="页脚导航"></nav>
- 浏览器内置的“跳至导航”快捷键（如 Chrome 的 Alt+F1）只响应 nav 元素
nav 里该放什么，不该放什么
放：
- 主要跳转入口，如首页、产品、博客、联系
- 同一逻辑层级的页面间链接（不是二级下拉项本身，而是触发下拉的父级按钮）
- 锚点链接（如 href="#features"），只要它是全局导航的一部分
不放：
文章转信息图。将文章/笔记转化为手机可读的 HTML 信息图，自动匹配视觉风格。触发场景：文章转图、笔记转图、信息图、转小红书图、做张图、可视化这篇文章、文生图。
- 面包屑（
breadcrumb）——应使用nav+aria-label="面包屑"单独包裹，不能混进主导航 - 登录/注册按钮（除非它直接跳转到独立登录页；否则表单操作不属于“导航”语义）
- 社交媒体图标链接（属于外链推广，不是网站内部导航路径）
- 仅用于布局或样式的空
nav—— 会干扰可访问性工具判断
常见错误：嵌套 ul 时漏掉关键属性
很多开发者写成这样：<nav><ul><li>@#@#@#@#@#@#@#@#@#@0</li></ul></nav>
看起来没问题，但实际踩了三个坑：
- ul 缺少 role="list"：旧版 Safari 和部分读屏器可能不识别其列表语义
- li 缺少 role="listitem"：当 CSS 重置了默认样式（如 list-style: none），语义可能丢失
- a 缺少 aria-current="page"：当前页面对应的导航项无法被辅助技术标记为“当前位置”，用户无法感知所处位置
正确写法示例：
<nav aria-label="主导航"><ul role="list">
<li role="listitem"><a href="/" aria-current="page">首页</a></li>
<li role="listitem"><a href="/about">关于我们</a></li>
</ul></nav>
移动端折叠菜单仍需保留 nav 语义
做汉堡菜单时，别因为 JS 控制显隐就改成 div class="mobile-nav"。
- 折叠状态下的导航容器仍必须是 nav，且保持 aria-label 不变
- 切换按钮（汉堡图标）需用 button 而非 div，并配 aria-expanded 和 aria-controls
- 被 JS 显隐的菜单内容，应放在同一个 nav 内部，不要动态创建/销毁整个 nav 元素——否则焦点管理会断，键盘用户可能卡在按钮上出不去
最常被忽略的一点：即使你用了 Flex 布局、写了媒体查询、加了动画，只要 nav 的语义结构没立住，所有样式和交互优化都只是“表面流畅”。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
