纯 CSS 下拉菜单用 :hover 即可实现桌面端悬停展开，但移动端必须用 JavaScript；定位偏移需给触发按钮父容器设 position: relative；显隐控制推荐 visibility: hidden + opacity 过渡；移动端闪退主因是事件冒泡，需 stopPropagation 或用 closest 判断。
下拉菜单必须用 :hover 还是得靠 JavaScript？
纯 CSS 下拉菜单在现代浏览器里完全可行，:hover 就够用——但仅限鼠标悬停；移动端点击展开必须加 JavaScript。别硬套“纯 CSS 万能”思路，否则在 iOS Safari 上点一下没反应，用户以为菜单坏了。
- 桌面端：用
:hover触发display: block或opacity/visibility动画最轻量 - 移动端：
:hover不稳定（iOS 会延迟触发甚至不触发），得监听click或用details/summary原生语义化方案 - 无障碍要求高时，
focus和keydown（如 Enter / 空格）也得支持，光靠:hover不够
position: absolute 的菜单定位为什么总偏移？
下拉项脱离文档流后，top 和 left 的参照物是最近的「已定位祖先元素」（即 position 为 relative、absolute 或 fixed 的父级）。如果忘了给菜单父容器加 position: relative，它就会往上一直找，最终相对 定位，导致飘走。
- 必须给触发按钮的直接父容器设
position: relative - 避免用
margin-top把菜单“推”到正确位置——这属于 hack，响应式下极易错乱 - 若父容器本身有
transform（比如用了scale或translate），它也会成为新的 containing block，可能造成意外偏移
用 display: none 还是 visibility: hidden 控制显隐？
二者行为差异直接影响可访问性和动画效果：display: none 彻底移出渲染树，屏幕阅读器读不到，也无法做 opacity 过渡；visibility: hidden 保留占位和语义，但看不见也点不了。
- 要过渡淡入淡出：用
visibility: hidden+opacity: 0组合，再配合transition - 要节省渲染开销、且不需要动画：
display: none更干净 - 用
aria-hidden="true"配合display: none，确保屏幕阅读器同步忽略隐藏菜单 - 别只切
opacity而不改visibility或display——透明但可聚焦、可点击，会破坏交互逻辑
移动端点击后菜单闪退，是什么原因？
典型表现是：点一下菜单弹出，立刻又收回去。根本原因是点击事件冒泡到了 或其他监听了全局 click 关闭菜单的逻辑上，而你的菜单还没来得及阻止默认或停止传播。
立即学习“前端免费学习笔记（深入）”；
- 给菜单容器的
click事件加e.stopPropagation() - 在 document 级关闭逻辑里，用
e.target.closest(".dropdown")判断点击是否在菜单内外，而不是简单if (!e.target.matches('.dropdown-trigger')) - 避免在
touchstart和click上重复绑定——移动端 click 有 300ms 延迟，容易误判两次 - 更稳妥的做法：用
focusout+setTimeout延迟关闭，给用户留出移入子菜单的时间
真正麻烦的从来不是写出来，而是让 hover、focus、click、touch、键盘、屏幕阅读器全走对同一套状态逻辑。漏掉任意一种，菜单就在某个场景下“失灵”。
