这不是bug，是iOS Safari对:hover的延迟清除机制：首次touchstart激活但无touchend终结，需滚动或焦点切换重置；须用@media (hover: hover) and (pointer: fine)精准限定鼠标/触控笔场景，并配合:active反馈或JS模拟is-hovered类确保跨端一致。
为什么:hover在iOS Safari里点一下就“卡住”不退
这不是bug，是浏览器对悬停状态的延迟清除机制——iOS Safari和部分Android Chrome会在首次touchstart时激活:hover，但没有对应的touchend事件来终结它。它依赖滚动、焦点切换或点击其他区域才能重置，而这些动作并不总发生，也不及时。
常见现象包括：.menu:hover { display: block; }点开后收不回去、.btn:hover { background: red; }点完还红着、原生<button>上高亮残留更顽固（因自带点击逻辑与CSS:hover并行）。
微信/QQ内置浏览器（X5内核）甚至完全忽略:hover更新，残留更难清除。
@media (hover: hover) 单独用为什么没用
@media (hover: hover)只判断设备“是否支持悬停能力”，不判断“此刻是否在用鼠标”。iPad接妙控板、Surface Pro用触控笔时，设备会同时上报hover: hover和pointer: coarse，导致你写的:hover样式在手指点一下后就“卡开”。
立即学习“前端免费学习笔记（深入）”；
必须叠加精度判断：@media (hover: hover) and (pointer: fine)才表示当前主输入方式既支持悬停，又足够精细（即鼠标、触控笔），自动排除所有手指触控。
注意：@media (hover: hover) and (pointer: coarse)是无效组合，W3C规范中二者互斥，这条永远不匹配。
:active为什么在iOS Safari上默认不生效
:active是移动端最稳的瞬时反馈替代方案，但它在iOS Safari默认被禁用，除非满足以下任一条件：
- 元素或其任意祖先绑定了
touchstart事件（最简做法：<body ontouchstart="">） - 元素本身是
<button>或带role="button"且有tabindex="0" -
cursor: pointer在移动端纯CSS声明无效，不能靠它触发
:active动画持续时间建议≤ 0.15s；别只改背景色，组合transform: scale(0.98) + opacity更可靠；父容器若设了overflow: hidden，可能裁掉缩放区域。
JS模拟is-hovered类时最容易漏掉的三件事
监听touchstart/touchend看似简单，但实操中常踩坑：
- 必须调用
e.preventDefault()，否则安卓部分机型会触发双击缩放或滚动中断 - 别在
touchend立即移除class——用户滑动时touchend不一定触发，推荐用setTimeout延迟300ms清除 - 如果元素有跳转行为（如
<a href="/next">），要在click回调里立即清除is-hovered，否则新页面样式被污染
真正难的从来不是怎么写:hover，而是怎么让它的边界在不同输入方式之间自然消失——它藏在pointer: fine的判定里，也藏在你忘了给父容器加will-change: transform的那一行注释里。
