移动端无 hover 事件是规范所致，并非 bug；应弃用 :hover 做关键交互，改用 :active 或 JS 控制 class 实现点击反馈与状态切换，确保触控兼容性与可访问性。
移动端没有 hover 事件，CSS :hover 不触发是正常行为
这不是 bug，是规范。iOS 和 Android 的触摸系统不模拟 hover 状态（除了极少数 Safari 的“伪 hover”延迟触发），:hover 在纯触屏设备上基本不可靠。依赖它做关键交互（比如展开菜单、显示提示）会导致功能缺失。
用 :active 或 JavaScript 模拟点击态更稳妥
对按钮、卡片等可点击元素，优先用 :active 做按下反馈；需要持久态（如展开/收起）必须交由 JS 控制 class。注意：:active 在 iOS 上默认有 300ms 延迟，需加 touch-action: manipulation 或使用 fastclick 库消除。
- 避免只写
a:hover { color: red; }—— 移动端用户点下去根本看不到变色 - 改用
a:active { color: red; }，并确保父容器有cursor: pointer（部分安卓浏览器需要） - 若需“悬停即展开”，改用点击触发：给元素加
data-toggle="dropdown"，JS 监听click切换.is-open类
Media Query 不能解决 hover 缺失问题
别用 @media (hover: hover) 来“检测是否支持 hover”然后启用样式——这只会让 CSS 更难维护，且无法覆盖真实用户行为（比如 iPad 连了鼠标但主操作仍是触控）。它适合微调，不适合决定核心交互逻辑。
-
@media (hover: hover) and (pointer: fine)可用于给桌面端加过渡动画，但不要用来控制是否显示下拉菜单 - 移动端菜单始终应默认可点击展开，而不是等“模拟 hover”才出现
- 这个媒体查询在 Chrome for Android 上返回
hover: none，但用户仍可能外接鼠标，行为不一致
真正安全的替代方案：语义化 + JS 驱动状态
把交互逻辑从 CSS 移到 JS，用 class 控制视觉状态，既兼容又可控。关键是保持 DOM 结构语义清晰，比如用 立即学习“前端免费学习笔记（深入）”； 而不是 button[data-dropdown] {
position: relative;
}
button[data-dropdown].is-open + .dropdown-menu {
opacity: 1;
visibility: visible;
transform: translateY(0);
}
.dropdown-menu {
opacity: 0;
visibility: hidden;
transform: translateY(-8px);
transition: opacity 0.2s, transform 0.2s;
}
CSS .is-open
.is-open，CSS 基于该 class 控制菜单显隐blur 或 touchstart 关闭菜单，避免点击空白处不收起Enter 或 Space 也能触发:hover 在移动端失效不是要绕开的问题，而是提醒你：交互设计不该假设输入方式。最易被忽略的是——即使加了 @media (hover: hover)，也掩盖不了“用户根本没把手指移过去，而是直接点了”的事实。
