移动端:hover点击后不消失是浏览器悬停状态延迟清除机制所致；iOS Safari等将首次触摸视为:hover起点但无对应“离开”事件，需通过ontouchstart属性或JS主动清除。
移动端点击后 :hover 样式不消失，不是 bug，是浏览器对悬停状态的延迟清除机制；@media (any-hover: hover) 不能可靠解决该问题，它只表示“设备*可能*支持 hover”，而非“当前正在用鼠标交互”。
为什么 :hover 在移动端点击后卡住不退
iOS Safari 和部分 Android Chrome 会把首次触摸当作 :hover 的起点，但没有对应的“离开”事件来终结它。滚动、切换焦点、甚至点空白处都可能触发清除，但不保证立即发生——这取决于浏览器内核对悬停栈的维护逻辑。真机上点按钮后背景色一直挂着，不是样式写错了，是悬停上下文没被主动释放。
常见错误现象包括：
- 返回上一页后，链接仍保持
:hover高亮 - 滑动页面时偶然蹭到按钮，之后长时间残留 hover 色块
- 同一套 CSS 在 PC 正常，在 iOS 微信内置浏览器中 hover 状态永不退出
@media (any-hover: hover) 的真实作用和陷阱
这个媒体查询判断的是“设备能力”，不是“当前输入方式”。只要设备硬件上*具备*精细指针（比如带触控板的 iPad），哪怕你正用手指点，(any-hover: hover) 也会为 true。它无法区分用户此刻是点还是悬停。
立即学习“前端免费学习笔记（深入）”；
实操建议：
- 不要用它做功能开关，比如
@media (any-hover: hover) { .btn:hover { background: #eee; } }—— 这在 iPad 上仍会生效，且旧版 X5 内核（微信/QQ 浏览器）直接忽略整条规则 - 若必须渐进增强，优先用
@media (hover: hover) and (pointer: fine)，兼容性稍好（iOS Safari 13.4+、Chrome 82+），但仍需 fallback - 把媒体查询块写在常规样式之后，否则会被普通
.btn:hover覆盖
真正有效的替代方案：用 :active + JS 清除或模拟
放弃依赖 :hover 做关键反馈。移动端最稳定的状态信号是 :active，但它在 iOS 上默认不触发，除非元素有 touchstart 监听器或 ontouchstart="" 属性。
实操建议：
- 给所有可交互元素加空属性：
<button ontouchstart="">提交</button>，多数内核会因此放弃维护 hover 状态 - 监听
touchstart，立即给document.body添加 class，如is-touching，然后用.is-touching .btn:hover { all: unset; }强制禁用 - 更彻底的做法：用 JS 动态增删
is-hovered类，配合.btn:hover, .btn.is-hovered双写法，兼顾语义与可控性
容易被忽略的关键点
很多人以为加个 @media 就一劳永逸，但实际线上环境里，X5 内核占比仍高，(hover: hover) 完全不识别；而单纯靠 :active 又会在 iOS 上失效——根本原因不是 CSS 写错，是没给元素注册 touch 事件。最轻量的兜底动作，就是在 <body> 上加 ontouchstart=""，不写 JS 也能破掉大部分 hover 残留。
