HTML下拉导航不必强制用嵌套<ul><li>，但几乎所有可靠实现都采用该结构——因:hover依赖父元素持续悬停状态，<div><span>等组合易导致下拉闪退、错位或层级失效。
HTML下拉导航必须用嵌套 <ul> + <li> 吗？
不是必须，但几乎所有可靠实现都这么干——因为浏览器对 :hover 的触发逻辑只认「鼠标进入/离开元素边界」，而纯 CSS 下拉依赖父元素持续 hover 状态。如果用 <div> 套 <span>，悬停移开时下拉菜单会闪退。
常见错误现象：display: none 的子菜单在鼠标移向它途中就消失了；或者菜单位置错乱、层级压不住其他内容。
- 必须保证父
<li>包裹触发元素（如<a>）和下拉容器（如<ul>），否则 hover 中断 - 下拉容器不能脱离父
<li>流式布局（比如用position: absolute但没设parent relative） - 移动端不响应
:hover，所以纯 CSS 方案在 iOS Safari 上默认失效
:hover 触发下拉时，为什么鼠标一偏就收起？
根本原因是：下拉区域和触发区域之间存在空白间隙。CSS 的 :hover 不会“跨空隙维持”，只要鼠标经过像素级的 gap，父元素 hover 就结束，子菜单立刻 display: none。
使用场景：导航栏横向排列，下拉菜单从 <li> 底部向下展开，但顶部没对齐或留了 margin/padding。
立即学习“前端免费学习笔记（深入）”；
- 把下拉
<ul>的margin-top设为0，并确保父<li>没有 bottom padding - 用
top: 100%+left: 0定位，而非靠 margin 推下来 - 必要时加一个「连接桥」：给父
<li>设置padding-bottom: 8px，同时让下拉<ul>的margin-top: -8px，视觉无缝，hover 不断连
用 <details> + <summary> 能替代下拉导航吗？
不能直接替代。虽然 <details> 原生支持展开收起，但它不支持 hover 自动展开、不支持多级嵌套、且无法用 CSS 精确控制下拉方向（比如右拉侧边栏）。
性能影响：<details> 是语义化方案，渲染开销略低，但交互逻辑被浏览器锁定，无法监听 hover 或添加过渡动画。
-
<details open>只能 JS 控制开关，不能靠 CSS:hover驱动 - Chrome/Firefox 支持尚可，但 Safari 对
<details>的position: absolute子元素兼容性差，常错位 - 如果只是单层、点击展开、不需要动画——它够用；要 hover、要多级、要样式自由，就得回退到
<ul>/<li>结构
移动端适配时，:hover 失效该怎么补？
iOS 和 Android Chrome 都把 :hover 当作「伪类」处理：第一次点击才激活，之后才响应 hover；但第二次再点别的菜单，上一个不会自动收起——这是最常被忽略的断裂点。
容易踩的坑：只写 CSS，不加任何 JS，结果用户在 iPhone 上点开一个菜单，再点另一个，两个同时开着，遮挡内容。
- 必须用 JS 监听
touchstart或click，手动切换aria-expanded和 class - 不要依赖
:hover做核心交互逻辑，把它当作「桌面增强」，而非主路径 - 检测
matchMedia("(hover: hover)")来分流：真 hover 设备走 CSS，否则走 JS 控制显隐
复杂点在于：你得同时维护两套状态同步逻辑——CSS 的 hover 显隐 + JS 的点击显隐，稍不注意就会出现「鼠标悬停显示，手指点击却关不掉」这种撕裂感。
