移动端纯:hover多级导航失效，须改用:focus-within+tabindex实现点击展开与键盘可访问，同时修复定位错位、z-index无效及悬停闪退问题。
hover触发的子菜单在移动端打不开怎么办
纯:hover实现的多级导航，在触屏设备上基本失效——手指悬停没有“悬停”概念，:hover只在模拟鼠标指针时短暂触发，且iOS Safari对嵌套:hover支持极弱。
真实场景中，这不是“兼容性差”，而是行为逻辑根本错位：桌面靠悬停展开，移动端必须靠点击切换显隐状态。
- 别试图用
@media (hover: hover)兜底——它只判断设备是否支持悬停，不解决“用户想点开却点不开”的问题 - 移动端必须引入
click事件或:focus-within配合tabindex，让父项可聚焦 - 如果坚持用纯CSS，可用
:focus-within+tabindex="0"让父<li>获得焦点后显示子菜单，但需确保键盘可访问
子菜单定位偏移或遮挡的常见原因
绝对定位的子菜单常错位，不是CSS写得不够“精准”，而是忽略了定位上下文和层叠顺序。
- 父级
<li>必须设position: relative，否则position: absolute的子菜单会相对于最近的position: relative/absolute/fixed祖先定位，容易跑偏 -
z-index只对定位元素生效，未设position的父容器即使写了z-index也无效 - 若导航栏在
transform容器（如轮播图、动画父层）里，子菜单可能被裁剪——加transform: translateZ(0)或改用will-change: transform可触发新层叠上下文
用:focus-within替代:hover做基础可访问方案
:focus-within是目前最接近“纯CSS点击展开”的解法，它在子元素获得焦点时激活父样式，配合tabindex就能让键盘用户和触屏点击（Safari/iOS 15.4+）都可用。
立即学习“前端免费学习笔记（深入）”；
.nav-item {
position: relative;
}
.nav-item:focus-within .submenu {
opacity: 1;
visibility: visible;
pointer-events: all;
}
.submenu {
opacity: 0;
visibility: hidden;
pointer-events: none;
transition: opacity 0.2s, visibility 0.2s;
}
- 给
<li class="nav-item">加tabindex="0"，让它能被Tab聚焦，也能被触屏点击触发focus -
pointer-events: none必须配visibility: hidden，否则不可见但占位、仍拦截点击 - 旧版Safari不支持
:focus-within，需降级为JS控制aria-expanded和display
多级嵌套时hover穿透与意外关闭
二级菜单展开后，鼠标从一级菜单移向二级时，若路径中有空隙，:hover会中断导致菜单闪退——这不是bug，是浏览器按盒模型逐帧检测悬停区域的自然结果。
- 在一级菜单和二级菜单之间加一个垂直方向的“连接条”，用
margin-bottom或伪元素撑开间隙，宽度建议≥10px - 二级菜单的
top值别写死，改用top: 100%，避免因字体大小、行高变化导致错位 - 不要依赖
transition-delay防闪退——延迟无法解决悬停中断本质，反而让交互变钝
真正难的不是写出能展开的菜单，而是让展开状态在各种缩放、滚动、焦点切换、屏幕旋转下都不意外丢失。hover只是起点，可访问性、触控反馈、焦点管理才是落地时绕不开的坎。
