移动端:hover不可靠，因无悬停物理状态；应通过ontouchstart添加has-touch类并用JS实现tap/click替代态，避免依赖媒体查询判断设备类型。
hover伪类在iOS/Android上根本不会按预期触发
移动端浏览器（尤其是Safari和Chrome for Android）对 :hover 的支持是“懒惰且延迟”的：它只在用户完成一次点击（tap）后，才临时激活一次 hover 状态，且持续时间极短；随后立即失效。这不是bug，而是规范行为——W3C 明确允许 UA（浏览器）在触摸设备上忽略或弱化 hover 响应，以避免误触和性能开销。
- 常见错误现象：
button:hover { background: red; }在iPhone上点一下才变红，松手即恢复，无法“悬停保持” - 使用场景：纯CSS下拉菜单、工具提示（tooltip）、卡片浮层等依赖持续 hover 的交互，在真机上基本失效
- 根本原因：移动设备没有“鼠标指针停留”这个物理状态，
:hover缺乏持续锚点
别用媒体查询判断“是否为触摸设备”来开关hover
@media (hover: hover) and (pointer: fine) 这类查询看似聪明，但实际不可靠——很多安卓平板、折叠屏、带触控笔的Windows设备会同时匹配 hover: hover 和 pointer: coarse，导致样式逻辑混乱；而 iOS Safari 甚至在某些版本里把 hover 媒体特性硬编码为 hover，不管是否真有鼠标。
- 参数差异：
(hover: none)并不等于“是手机”，它可能只是当前输入模式为触摸（比如Surface平板切到触控模式） - 兼容性影响：依赖此判断做CSS切换，会导致PC端外接触摸屏时hover失效，或移动端误启用hover动画
- 实操建议：放弃用CSS媒体查询做设备类型决策；把交互控制权交给JS
用 ontouchstart 标记触摸环境并降级样式
最稳妥的做法是在页面加载时，用一次 ontouchstart 事件监听（不冒泡、只监听一次）打上 class="has-touch" 到 上，然后在CSS中用 .has-touch button:hover 强制禁用或替换 hover 效果。
if ('ontouchstart' in window || navigator.maxTouchPoints > 0) {
document.documentElement.classList.add('has-touch');
}
- 为什么这样做：比
matchMedia更直接、更早触发，且不依赖UA字符串或渲染时机 - 容易踩的坑：不要用
'touchstart' in window—— 很多桌面浏览器也支持该事件名，但不意味着有触摸能力 - 性能影响：仅执行一次，无运行时开销；CSS选择器层级略深，但现代浏览器优化良好
hover效果必须有对应的tap/click替代态
所有依赖 :hover 的视觉反馈，都得有明确的 :active 或 JS 控制的 .is-active 状态兜底。例如下拉菜单不能只靠 nav li:hover ul 显示，而应改用 nav li:active ul, nav li.is-open ul，再由JS在tap时切换 is-open。
立即学习“前端免费学习笔记（深入）”；
- 使用场景：导航菜单、图片放大预览、表单项焦点提示
- 关键细节：iOS Safari 对
:active有300ms延迟，需加body { -webkit-tap-highlight-color: transparent; }并确保元素可点击（如加cursor: pointer或role="button"） - 复杂点在于：有些交互需要“按住显示，松开隐藏”，这只能靠
touchstart/touchend+ 定时器模拟，无法用纯CSS实现
