不是必须但强烈建议用包裹导航菜单，因其提供语义化识别、提升可访问性和seo；+是唯一稳定可靠的结构；键盘可用性需确保焦点流可控、aria状态同步、子菜单自动聚焦与esc收起。
导航菜单必须用 <nav></nav> 包裹吗？
不是必须，但强烈建议。浏览器和读屏软件会把 <nav></nav> 当作语义化导航区域识别，跳过它或用 <div> 替代，会导致辅助技术用户无法快速定位菜单，SEO 也可能弱化导航权重。
<p>实际开发中常见错误：只加 class（如 <code>class="navbar"）却不加语义标签，或者把整个页眉都塞进一个 <nav></nav> 里——导航区域应只包含真正用于页面跳转的链接集合。
<ul></ul> + <li> 是唯一靠谱的结构吗？
是目前最稳定、兼容性最好、语义最清晰的写法。用 <div> 堆链接或用 <code><p></p> 包单个链接，会丢失列表层级关系，影响键盘 Tab 顺序、屏幕朗读节奏，也增加 CSS 重置成本。
关键细节：
-
<ul></ul>适合平级导航（如顶部主菜单），<ol></ol>不适用——导航项没有天然序号含义 - 下拉子菜单必须嵌套在父
<li>内，而不是独立<ul></ul>，否则逻辑断裂 - 每个
<a></a>必须有明确href；空链接（href="#"）或javascript:void(0)会破坏可访问性和 SEO
如何让键盘用户能真正用上这个菜单？
光有结构不够，焦点流和键盘操作必须可预测。纯 CSS 下拉菜单常忽略这点，导致按 Tab 键直接跳过子项，或 Esc 无法关闭展开状态。
实操要点：
- 默认隐藏子菜单时，用
display: none或visibility: hidden，别用opacity: 0+pointer-events: none——后者会让键盘焦点“穿过去” - 子菜单出现后，第一个链接需自动获得焦点（用 JavaScript 的
.focus()），否则键盘用户得连按多次 Tab 才能进入 - 按
Esc应收起当前展开的子菜单，且焦点回到触发它的父链接 - 用
aria-expanded和aria-haspopup标注展开状态，屏幕阅读器才知这是可交互菜单
响应式折叠菜单（汉堡按钮）最容易漏掉什么？
视觉上收起不难，但可访问性崩塌往往发生在 JS 控制显隐的那一刻。
典型坑点：
- 点击汉堡图标展开菜单后，没把
aria-expanded="true"同步设到按钮上，屏幕阅读器仍读作“打开菜单”，实际已展开 - 菜单弹出时，没用
inert属性或aria-hidden="true"让背景内容“失焦”，键盘用户仍能 Tab 到后面按钮 - 移动端触摸后没加
touch-action: manipulation，导致 300ms 延迟，点击反馈滞后 - 没监听
resize事件重新校验断点——窗口从手机宽度拖大回桌面宽度时，菜单可能卡在“已展开”状态却无视觉提示
复杂点不在布局，而在状态同步：DOM 属性、焦点位置、ARIA 标记、CSS 显隐，四者必须严格一致。少一个，菜单对某类用户就等于不存在。
