:hover 在触屏设备上不可靠，应使用 @media (hover: hover) and (pointer: fine) 判断真悬停能力，并为触控用户优先采用 :active 或 js 模拟交互反馈。
别指望 :hover 在触屏设备上稳定工作——它不是“失效”，而是浏览器根本没打算让它持续生效。 iOS Safari 和 Android Chrome 会把第一次触摸当作一次临时悬停，然后立刻退出；后续再点，:hover 样式可能闪一下、卡住、或干脆不触发。这不是你写错了选择器，是交互模型不同导致的必然结果。
用 @media (hover: hover) and (pointer: fine) 包裹鼠标专属样式
这个媒体查询才是判断“真悬停能力”的唯一靠谱方式。@media (hover: hover) 单独用在 iPad 上恒为 true，完全不可靠；必须叠加 pointer: fine 才能排除手指（pointer: coarse）干扰。
- 所有依赖持续悬停的视觉效果（如下拉菜单展开、卡片浮层、过渡动画）都得包进这个查询里
-
transition属性也得一起包进去，否则 Safari 可能解析了 transition 却不触发 hover，造成 Vue/React 组件重渲染时意外动画 - 必须写在常规样式之后，否则会被
.btn:hover直接覆盖 - 别写
@media (hover: hover) and (pointer: coarse)—— W3C 规范中这两者互斥，这条规则永远不匹配
给所有 :hover 元素加 :active 替代反馈
:active 是移动端最稳的瞬时反馈方案，但它在 iOS Safari 默认不触发，除非满足以下任一条件：
- 元素或其祖先绑定了
touchstart事件（最简做法：） - 元素是
<button></button>或带role="button"且有tabindex - 设置了
cursor: pointer（注意：纯 CSS 声明在移动端被忽略，无效）
实操建议：:active 动画持续时间 ≤ 0.15s；别只改背景色，组合 transform: scale(0.98) + opacity: 0.9 更自然；父容器若设了 overflow: hidden，可能裁掉缩放区域。
用 JS 模拟 is-hovered 类要避开三类坑
监听 touchstart/touchend 并手动切 class 看似灵活，但容易出问题：
- 滚动干扰：页面滚动时触发
touchstart，误判为点击，样式异常激活 - 状态残留：快速连点多个元素，前一个的
is-hovered类可能没清除就重复添加 - 内存泄漏：单页应用中组件反复挂载/卸载，没做事件清理就会累积监听器
更稳妥的做法是用事件委托，在父容器监听 touchstart，靠 event.target.matches('[data-hoverable]') 判断目标；移除时用 setTimeout(() => el.classList.remove('is-hovered'), 300)，避开 iOS 的 300ms click 延迟窗口；同时监听 touchcancel 防止滑动中断后状态卡死。
真正容易被忽略的点：元素必须被识别为“可交互”
即使写了 @media (hover: hover) and (pointer: fine) 和 :active，如果元素没被浏览器识别为“可交互”，这些伪类依然不会触发。确保：
- 非
<button></button>的<div> 或 <code><span></span>至少有tabindex="0"或role="button" - 父容器不能包裹整个视口（比如
overflow: hidden的全屏div），否则可能拦截事件流 - 不要依赖 UA 字符串判断设备类型——桌面版 Chrome 也可能暴露
ontouchstart，iOS 17+ 同样如此
最后提醒一句：别把 :hover 当作核心交互逻辑的开关。它只适合渐进增强，比如给鼠标用户加个平滑过渡；而触控用户的反馈路径，必须由 :active 或 JS 显式控制。
