导航菜单不必强制用<nav>包裹，但主导航区域强烈建议使用以提升可访问性和SEO；<ul>+<li>是语义最准确、兼容性最佳的实现方式；下拉菜单需保持DOM层级并正确标注ARIA属性；移动端应复用同一HTML结构，仅通过CSS/JS控制显隐与焦点。
导航菜单必须用 <nav> 包裹吗？
不是必须，但强烈建议。浏览器和屏幕阅读器会把 <nav> 当作独立导航区域识别，提升可访问性；不加的话，语义缺失，SEO 和辅助技术体验都会打折扣。实际开发中，如果只是页脚几个链接或侧边小入口，用 <div> 也行，但主顶部/侧边栏导航，请务必套 <nav>。
<ul> + <li> 是唯一正解？
是当前最通用、最稳妥的实现方式。原因很实在：<ul> 天然表达“一组并列项”，<li> 明确每个菜单项的边界，CSS 重置和 hover/focus 样式控制都更干净。虽然有人用 <div> 堆按钮，或者用 <ol>（误以为有顺序），但前者语义丢失，后者逻辑错位——导航项没有固有数字顺序。
常见错误现象：
- 用
<p>或<span>直接写链接：无法被键盘 Tab 正确遍历，焦点管理混乱 - 嵌套多层
<ul>却没加aria-haspopup="true"和aria-expanded：下拉菜单对屏幕阅读器不可见 - 给
<li>加display: inline而不是display: inline-block或 flex：垂直对齐错乱，点击热区缩水
下拉菜单的 HTML 结构怎么写才不出错？
核心原则：子菜单仍是导航的一部分，不能脱离语义流。正确结构是子 <ul> 作为父 <li> 的直接子元素，且需明确标注可展开状态。
立即学习“前端免费学习笔记（深入）”；
实操要点：
- 父
<li>加role="menuitem"，子<ul>加role="menu" - 子菜单默认隐藏（
display: none），展开时设aria-expanded="true"到父链接上 - 每个子项用
<a>或<button>，避免用<div>模拟点击——否则键盘 Enter/Space 无法触发 - 不要把子
<ul>提到 body 下做“飞出式”绝对定位：破坏 DOM 层级，焦点流断裂，屏幕阅读器找不到上下文
示例片段：
<nav>
<ul>
<li>
<a href="#" aria-haspopup="true" aria-expanded="false">产品</a>
<ul role="menu" style="display: none;">
<li role="menuitem"><a href="/app">桌面端</a></li>
<li role="menuitem"><a href="/web">网页版</a></li>
</ul>
</li>
</ul>
</nav>
移动端响应式菜单要不要改 HTML 结构？
不需要。HTML 结构应保持稳定，仅靠 CSS 和少量 JS 控制显隐与布局。改结构（比如切换成 <select>）会导致语义断裂、样式难复用、JS 逻辑膨胀。
关键做法：
- 用媒体查询控制
<nav>内部<ul>的 display / flex-direction - 汉堡按钮用
<button>而非<div>，确保可聚焦、可键盘操作 - 展开后用
inert属性或aria-hidden="true"隐藏未激活区域，防止键盘跳转到不可见菜单项 - 避免用
visibility: hidden隐藏菜单：元素仍在可访问树中，屏幕阅读器仍会读出
真正容易被忽略的是焦点管理：菜单展开后，焦点应自动移到第一个菜单项；收起后，焦点应回到汉堡按钮。这点纯 CSS 做不到，必须 JS 补位。
