移动端 :hover 不可靠是因触控设备无悬停状态，浏览器弱化或延迟模拟，首次 touchstart 后状态易锁定，需滚动或点击其他区域重置；:active 需绑定 touchstart 或设为 button 才生效，且动画宜≤150ms并组合 transform 与 opacity。
因为移动端没有“悬停”这个物理输入状态，:hover 在触控设备上本就不该被设计为可靠交互依据——它不是失效，而是被浏览器有意弱化或延迟模拟。
为什么点一下按钮背景色就卡住不退
iOS Safari 和部分 Android Chrome 会在首次 touchstart 后短暂激活 :hover，但没有对应的 “悬停结束” 事件来清除它。系统会把这个状态锁住，直到你滚动页面、点击其他区域或切换焦点才重置。这不是 bug，是规范行为：W3C 允许 UA（浏览器）在触摸设备上自由决定是否响应 :hover。
- 真机上点完按钮背景色挂着，大概率就是这个悬停上下文没被释放
-
<button></button>比<div> 更难控制，因为原生控件自带高亮逻辑，和 CSS <code>:hover并行运行且优先级不受你控制 - 微信 X5 内核、旧版 QQ/UC 浏览器甚至完全忽略
:hover状态更新，残留更顽固 - 必须写成
@media (hover: hover) and (pointer: fine)，才能排除所有手指触控场景 -
@media (hover: hover) and (pointer: coarse)是无效组合，W3C 规范里二者互斥 -
transition属性也得包进同一媒体查询里，否则移动 Safari 可能解析到动画却无法触发 - 顺序很重要：媒体查询块必须放在常规样式之后，否则会被普通
.btn:hover覆盖 - 元素或其任意祖先绑定了
touchstart事件（最简做法：） - 元素本身是
<button></button>或带role="button"且有tabindex="0" -
cursor: pointer在纯 CSS 中对移动端无效，不能靠它激活:active - 必须在
touchstart中调用e.preventDefault()，否则安卓部分机型会触发双击缩放或滚动中断 - 别在
touchend立即移除is-hovered——用户滑动时touchend很可能不触发；推荐用setTimeout延迟 300ms 清除 - 如果元素是
<a href></a>或有跳转行为，要在click回调里立即清除is-hovered，否则新页面加载后样式被污染
@media (hover: hover) 单独用等于白写
这个媒体查询只回答“设备是否支持悬停”，不回答“此刻是不是鼠标在操作”。iPad 接妙控板、Surface Pro 触控笔等设备会同时上报 hover: hover 和 pointer: coarse，导致你写的 .menu:hover { display: block; } 在手指点一下后就“卡开”。
:active 在 iOS Safari 上默认不生效
:active 是移动端最稳的瞬时反馈替代方案，但它在 iOS Safari 默认被禁用，除非满足以下任一条件：
另外，:active 动画持续时间建议 ≤ 150ms；不要只改背景色，组合 transform: scale(0.98) + opacity: 0.9 更符合触控反馈直觉。
JS 模拟 is-hovered 类最容易漏掉的三件事
手动控制类名看似可控，但触控事件生命周期比鼠标复杂得多：
真正让 :hover 兼容失效的，往往不是伪类本身，而是周围环境：父容器设了 overflow: hidden，缩放动画可能被裁掉；忘了给元素加 tabindex="0"，导致它不被识别为可交互目标；或者 transition 的 timing-function 在 Safari 里意外卡顿。
