多级导航菜单必须用嵌套结构，子菜单为父的直接子节点，配合aria-haspopup/expanded、role="menu"/"menuitem"、:focus-within+:hover显隐及js移动端控制，确保键盘、屏幕阅读器和触屏可用。
多级导航菜单不是靠“加个下拉效果”就能跑通的，结构错了，键盘跳不过去、屏幕阅读器读错、移动端点不开——这些都不是样式问题，是语义和 DOM 层级问题。
必须用 <ul></ul> 嵌套，子菜单得是父 <li> 的直接子节点
常见错误是把子菜单抽出来单独放页面底部，再用 CSS 定位“飞”上去。这会导致：
-
Tab键完全跳过子菜单项：浏览器只按 DOM 顺序 tab，<div class="submenu"> 不在父 <code><li>里，就等于不存在于导航流中 -
aria-expanded绑定失效：它该控制的是“这个菜单项是否展开”，而不是一个漂浮的<div> <li>iOS Safari 点击无响应：<code>:hover在触屏设备上不触发，又没 JS 补救，用户点一次根本打不开
正确写法只有一种：<ul></ul> 套 <ul></ul>，且内层 <ul></ul> 必须紧贴在父 <li> 的末尾：
aria-expanded 和 aria-haspopup 得配对用
只加 aria-expanded="false" 不够，屏幕阅读器需要知道“这东西能展开”，否则会当成普通链接读。
- 所有含子菜单的
<a></a>或<button></button>必须带aria-haspopup="true" - 初始状态设
aria-expanded="false"；JS 展开时同步改为"true" - 别忘了给子菜单加
role="menu"，每个子项加role="menuitem"
示例：
CSS 显隐逻辑必须用 :focus-within + :hover 双保险
纯 :hover 在触屏设备上失效；纯 JS 控制又绕不开键盘焦点。稳妥做法是同时响应两种状态：
- 桌面端靠
:hover触发子菜单显示 - 键盘用户靠
:focus-within（父<li>获焦时连带展开） - 子菜单用
position: absolute+top: 100%，确保不撑开布局 - 别设
display: none初始态——用visibility: hidden+opacity: 0配合transition，避免重排
关键 CSS 片段：
.has-submenu:hover .submenu,
.has-submenu:focus-within .submenu {
visibility: visible;
opacity: 1;
pointer-events: all;
}
.submenu {
position: absolute;
top: 100%;
left: 0;
visibility: hidden;
opacity: 0;
transition: opacity 0.2s, visibility 0.2s;
}
移动端点击展开必须用 JS，且要防冒泡
触屏设备没有 :hover，也不能依赖 focus（点击即失焦），必须 JS 干预：
- 监听
click，但要在e.stopPropagation()，否则父级<a></a>默认跳转会触发 - 优先用
<button></button>替代<a href="#"></a>，更语义、默认不跳转 - 展开后自动聚焦第一个子项，方便键盘用户继续操作
- 点击空白处或 ESC 键收起，这是可访问性硬要求
最小可用 JS：
document.querySelectorAll('.has-submenu > button').forEach(btn => {
btn.addEventListener('click', e => {
e.stopPropagation();
const submenu = btn.nextElementSibling;
const expanded = btn.getAttribute('aria-expanded') === 'true';
btn.setAttribute('aria-expanded', !expanded);
submenu.style.display = expanded ? 'none' : 'block';
if (!expanded) submenu.querySelector('a')?.focus();
});
});
最常被忽略的点：子菜单的 <ul></ul> 必须紧跟在父 <li> 里，不能用 JS 动态插入到别处；aria-expanded 和 DOM 展开状态必须严格同步；移动端点击逻辑不能只靠 CSS 模拟。
