:active在触摸屏“卡住”实为:hover残留，因ios safari等将首次触摸误判为悬停起点且缺乏明确退出事件；真机调试需检查devtools中是否真有:active高亮，而非:hover激活。
为什么 :active 在触摸屏上“卡住”不消失？
这不是样式写错了，也不是浏览器 bug，而是 iOS Safari 和部分 Android WebView 对悬停状态的延迟清除机制在起作用。用户第一次触摸某个元素后，浏览器会把它当作 :hover 的起点，但没有明确的“手指移开并离开区域”的事件来终结它——滚动、切页、点空白处才可能触发清除，且不保证立即发生。
常见现象是：点完按钮，背景色一直挂着，再点别的地方也不退。尤其当元素没被识别为可交互（比如纯 div 无 role="button" 或 tabindex="0"），或父容器设置了 pointer-events: none，问题更明显。
根本原因在于：:active 和 :hover 在移动端常被混用，而它们的触发逻辑完全不同：:active 理论上只在按住瞬间生效，但某些 WebView 会把首次触摸误判为“进入悬停态”，进而让 :hover 残留，视觉上看起来像 :active 卡住了。
如何判断真是 :active 还是 :hover 残留？
真机调试时，打开 DevTools 的 Elements 面板，手动点击目标元素，观察右侧 Styles 栏中是否真的出现了 :active 的高亮标记（不是 :hover）。如果只有 :hover 被激活，说明问题出在媒体查询或语义缺失上。
验证方法：
- 给元素加
cursor: pointer，看是否立刻有反馈（部分安卓 WebView 依赖这个触发 active 检测） - 检查是否写了
@media (hover: hover)—— 注意必须带值，@media (hover)整条规则会被忽略 - 确认该元素是否能获得焦点：用键盘 Tab 切换，看是否能高亮；不能的话，大概率
:focus也失效，:active更难触发
移动端 :active 卡住的典型诱因 很多“卡住”其实是伪类没被正确触发，然后开发者又加了错误的兜底逻辑，导致状态滞留。
常见诱因包括：
-
touchstart中调用了event.preventDefault()，它会中断原生点击链，连带阻止:active激活 - 父容器设置了
touch-action: none或pointer-events: none，事件根本传不到子元素 - 动态插入的元素（如 Vue/React 组件挂载后新增的按钮），未重新绑定 touch 事件或未触发“触摸唤醒”
- 页面缺少
<meta name="viewport" content="width=device-width, initial-scale=1">，导致 iOS Safari 拒绝启用交互状态栈
真正可靠的替代方案不是修 :active，而是绕过它
:active 天生就是瞬态的，毫秒级，靠它做持久反馈注定失控。如果你发现它“卡住”，往往意味着你本就不该依赖它来维持状态。
建议做法：
- 需要瞬时反馈（比如按钮按压动画）：用
touchstart/touchend手动切is-pressed类，配合transform: scale(0.98)，比改background-color更稳 - 需要点击后保持状态（比如选中态）：用
:focus（适合表单控件）或 JS 控制is-active类，别硬塞给:active - 所有自定义按钮（非
<button></button>）必须加role="button"+tabindex="0"+touch-action: manipulation，三者缺一不可
:active 样式，只要元素没被浏览器识别为“可交互”，它就永远不会触发——不是延迟，是彻底跳过。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
