移动端:hover残留非bug而是浏览器延迟判定逻辑所致，ios safari及部分android chrome将首次触摸视为悬停开始却无对应结束事件，需滚动或焦点切换才清除。
移动端 :hover 触发后样式不消失（触摸残留）
真机上点一下按钮，:hover 样式卡住不退，再点别的地方也没用——这不是 bug，是浏览器在触摸场景下对 :hover 的延迟判定逻辑导致的。iOS Safari 和部分 Android Chrome 会把第一次触摸当作“悬停开始”，但没有对应的“悬停结束”事件，直到用户主动触发另一个非触摸相关动作（比如滚动、焦点切换），才会清掉 :hover 状态。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 别依赖
:hover做关键交互反馈（比如仅靠它显示菜单或切换状态） - 给所有带
:hover的元素加:active显式覆盖，且确保:active样式与默认态一致（避免视觉跳变） - 在
touchstart事件里给 body 加个临时 class，比如is-touching，然后用.is-touching .btn:hover强制禁用 hover 效果 - 更彻底的做法：用
@media (hover: hover) and (pointer: fine)包裹纯鼠标用的:hover样式，让触摸设备直接跳过整段规则
@media (hover: hover) 的实际兼容性边界
这个媒体查询不是“有没有触摸屏”的判断，而是“当前输入方式是否支持精细悬停”。iOS Safari 13.4+、Chrome 82+、Firefox 68+ 支持，但旧版微信内置浏览器（X5 内核）、UC、QQ 浏览器等基本不识别，会直接忽略整个块。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 不要把它当“开关”来写核心功能样式，只用于渐进增强（比如给鼠标用户加过渡动画，触摸用户就直出）
- 检查目标用户 UA，若大量使用 X5 内核（尤其国内安卓 App 内嵌页），得准备降级方案：比如统一用
:active+ JS 模拟 hover 效果 - 注意顺序：把
@media (hover: hover)块写在常规样式后面，否则会被覆盖
用 JavaScript 主动清除 :hover 状态的可行路径
不能直接操作伪类，但可以间接影响它的触发条件。最稳定的方式是模拟一次“失去悬停上下文”的行为。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 监听
touchstart，立即对 document.body 执行body.style.touchAction = 'manipulation'（部分老版本需要） - 在
touchend后 300ms 内，强制触发一次body.focus()（哪怕 body 不可聚焦，也能重置悬停栈） - 更轻量做法：给触发元素加一个空的
ontouchstart=""属性，某些内核会因此放弃维护 hover 状态 - 慎用
document.documentElement.classList.add('force-no-hover')配合 CSS 覆盖，因为 class 切换有延迟，可能闪一下
为什么 :hover 在 <button></button> 上比在 <div> 上更难控制
<p>原生表单控件（<code><button></button>、<a></a>）在移动端有独立的点击高亮逻辑，和 CSS :hover 并行运行。系统高亮（如 iOS 的灰色 overlay）可能遮挡你写的 hover 样式，而你写的 :hover 又可能被高亮结束后残留的伪类干扰。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 统一用
-webkit-tap-highlight-color: transparent关掉系统高亮（记得同时设user-select: none防误选） - 对
<button></button>使用:not(:disabled):active替代:hover做按压反馈，更可靠 - 如果必须保留
:hover，把button:hover的 transition duration 设为 0，避免残留动画拖尾
真正麻烦的不是怎么写 hover，而是怎么让不同内核在不同触发路径下都“忘记”它。很多问题表面是样式残留，根子是浏览器没收到明确的“悬停已结束”信号——而这个信号，在触摸世界里根本不存在。
