这不是 bug，是浏览器未设计“手指离开即清除”机制；ios safari和android chrome将touchstart视为:hover起点，但无对应事件通知手指离开，需依赖滚动等外部动作被动重置。
这不是 bug，是浏览器根本没设计“手指离开即清除”的机制。 iOS Safari 和 Android Chrome 会把第一次 touchstart 当作 :hover 的起点，但没有对应的事件告诉它“手指已离开、该清除了”——它得等滚动、切页、点空白处这类外部动作来被动重置，而这些都不及时、不保证发生。
为什么点完按钮背景色还挂着
移动端没有 mouseover/mouseout 概念，:hover 是浏览器为兼容 PC 样式做的模拟行为。真机上残留，大概率就是悬停上下文（hover context）卡在了渲染层里没被释放。
-
<button></button>比<div> 更难控制，因为原生控件自带高亮逻辑，和 CSS <code>:hover并行运行，互相干扰 - 微信/QQ 内置浏览器（X5 内核）甚至忽略
:hover状态更新，残留更顽固 - 快速连点多个元素时，前一个的
:hover可能还没退，后一个又触发，视觉上像“全选中” - 必须写成
@media (hover: hover) and (pointer: fine)，才能排除所有手指触控场景 - 这条规则必须放在常规样式之后，否则会被
.btn:hover直接覆盖 -
transition属性也得包进同一媒体查询里，否则移动 Safari 可能解析到却不用 -
@media (hover: hover) and (pointer: coarse)是无效组合，W3C 规范里二者互斥，永远不匹配 - 元素或其任意祖先绑定了
touchstart事件（最简做法：） - 元素本身是
<button></button>或带role="button"且有tabindex="0" - 设置了
cursor: pointer（注意：纯 CSS 声明在移动端被忽略，仅作辅助标记）
@media (hover: hover) 单独用等于白写
这个媒体查询只回答“设备能不能悬停”，不回答“此刻是不是鼠标在操作”。iPad 接妙控板、Surface Pro 用触控笔时，会同时上报 hover: hover 和 pointer: coarse，导致你写的 .menu:hover { display: block; } 在手指点一下后就“卡开”。
:active 不是万能解，但它是唯一可控的瞬时反馈
:active 在手指按下瞬间触发、松开即失效，行为最接近 PC 端的 :hover + :active 组合。但它在 iOS Safari 默认不生效，除非满足以下任一条件：
动画持续时间建议 ≤ 0.15s；别只改背景色，组合 transform: scale(0.98) + opacity: 0.9 更自然；父容器若设了 overflow: hidden，可能裁掉缩放区域。
真正容易被忽略的是：即使写了 @media (hover: hover) and (pointer: fine) 和 :active，如果元素没被浏览器识别为“可交互”，这些伪类依然不会触发。确保它有 tabindex="0"（对非 <button></button> 的 <div> 尤其关键），且不能包裹在 <code>pointer-events: none 的父容器里。
