17370845950

移动端无 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;
}