必须用<nav>而非<div>或<section>，因其是唯一明确标识导航链接集合的语义标签；浏览器、屏幕阅读器和搜索引擎依赖该标签识别导航意图，缺失则导致辅助技术无法跳转、SEO丢失权重。
导航区域必须用 <nav>，不是 <div> 或 <section>
浏览器、屏幕阅读器和搜索引擎靠标签名判断内容意图。<nav> 是唯一明确表示“这是导航链接集合”的语义标签。用 <div class="nav"> 或 <section> 包裹链接，等于主动放弃语义——辅助技术无法跳转到该区域，SEO 也无法识别其导航权重。
常见错误现象：
- 侧边栏里一堆链接，却用
<div id="sidebar">包裹 - 页脚里放“关于我们”“联系方式”等链接，也套
<section> - 移动端下拉菜单用
<ul>直接挂在<body>下，没父级<nav>
正确做法：
- 只要是一组用于跳转到其他页面或锚点的链接（无论位置在顶、侧、底），且属于网站主干导航，就应包裹在
<nav>中 - 一个页面可有多个
<nav>（如主导航 + 面包屑 + 页脚导航），但每个都应有明确作用，避免滥用 -
<nav>内部推荐用<ul>/<li>组织链接，结构清晰且天然支持键盘 Tab 导航
<nav> 和 <header> 嵌套时，别把整个页头都塞进去
<header> 是区域容器，<nav> 是功能模块——两者职责不同。常见误写是：<header><nav>...</nav><h1>标题</h1></header> 看似合理，但若 <header> 还包含 logo 图片、搜索框、用户登录入口等非导航内容，再把整个 <header> 当作 <nav> 就错了。
立即学习“前端免费学习笔记（深入）”；
使用场景：
- 主导航栏通常位于
<header>内部，但只把链接部分交给<nav> - logo 和标题属于页头信息，应留在
<header>里但不在<nav>中 - 搜索框如果独立于导航逻辑（比如不参与站点全局跳转），建议用
<form>单独包裹，而非硬塞进<nav>
性能影响：嵌套过深不会拖慢渲染，但语义错位会降低爬虫提取准确率——搜索引擎可能把 logo 的 alt 文本误判为导航关键词。
固定侧边栏导航仍需 <nav>，CSS 定位不改变语义
用 position: fixed 或 sticky 实现的侧边栏，视觉上脱离文档流，但 HTML 结构语义不变。不能因为“它浮在右边”，就改用 <aside> 或 <div> 替代 <nav>。
关键判断点：
- 这个侧边栏是否提供页面内锚点跳转（如目录导航）或跨页链接（如产品分类）？→ 是，必须
<nav> - 它是否只是广告、作者简介、相关文章推荐？→ 否，这类才适合
<aside>
容易踩的坑：
- 以为“固定定位 = 辅助内容”，结果把导航塞进
<aside>，导致屏幕阅读器跳过它 - 用 JavaScript 动态插入导航 DOM，但没补上
<nav>标签，仅靠 class 名模拟 - 响应式断点中隐藏了
<nav>，但未配合aria-hidden或移除 tabindex，造成焦点陷阱
多语言/多版本网站的导航语义要分层处理
当导航含语言切换或地区版本（如 /en/ /ja/ /cn/），语义层级更敏感。单纯给 <nav> 加 lang 属性不够，需结合 <link rel="alternate"> 和 hreflang，但 HTML 结构本身仍要守住底线。
实操建议：
- 语言切换器本身是一组导航链接，仍应放在
<nav>中，可加aria-label="Language selector"明确用途 - 不要把整站多语言导航混在一个
<nav>里；主站导航和语言切换建议拆成两个<nav>，便于辅助工具区分 - 服务端渲染时，若根据用户地区返回不同导航结构，确保每个版本的 HTML 都保留
<nav>，而非只在 JS 中动态 patch
最易被忽略的一点：语义化不是“加了标签就完事”。<nav> 必须真实承载导航功能——如果里面塞的是纯文本说明、空链接或 JavaScript 跳转但无 href，那标签再标准也没意义。
