移动端 :active“慢半拍”是因 iOS Safari 及 WebKit 内核 WebView 默认启用 300ms 点击延迟以支持双击缩放，导致 :active 样式无法即时触发；推荐方案为在可点击元素上设置 touch-action: manipulation 或添加 ontouchstart=""，并真机验证。
为什么移动端 :active 总是“慢半拍”
不是你 CSS 写错了，而是 iOS Safari 和大部分 WebKit 内核 WebView（比如微信、QQ 内置浏览器）默认启用 300ms 点击延迟——它在等你双击缩放。这期间 :active 根本不触发，松手后才闪一下，甚至完全没反馈。
常见现象：button:active 在桌面 Chrome 里正常变色，放到 iPhone 微信里点击无反应；div 加了 :active 样式但按下去纹丝不动；真机测试时发现某些按钮第一次点总卡顿，之后才正常。
- 延迟发生在事件捕获阶段，
:active是样式层表现，依赖底层是否认定“已激活”，而 WebKit 卡住了这个链路 -
:active在规范中只对语义化可交互元素（如button、a）稳定生效，div上硬加基本靠运气 - Android 主流浏览器（Chrome/Firefox）通常实时响应，iOS 才是重灾区
touch-action: manipulation 要加在哪儿才有效
这是目前最轻量、最推荐的解法，但加错位置等于白写。
- 必须作用于具体可点击元素，比如
button、a、或带role="button"的div，不能只写在body或html上——否则页面无法双击缩放、滚动可能异常 -
touch-action不继承，父容器设了，子元素仍为auto，得单独加 - 检查 DevTools 的 Computed 面板，确认最终生效值确实是
manipulation，而不是被其他规则覆盖或写成touch-action: manipulation !important（语法错误，会被忽略） - 如果元素同时监听了
touchmove或设置了ontouchstart，部分浏览器会主动降级回 300ms 行为，此时需权衡手势逻辑是否必要
给元素加 ontouchstart="" 就够了吗
对很多场景来说，够了，但有细节陷阱。
立即学习“前端免费学习笔记（深入）”；
-
ontouchstart=""（空字符串）能提前告诉浏览器“这个元素要响应触摸”，从而激活:active即时渲染，比 JS 绑定更轻量 - 仅适用于明确需要点击反馈的元素，比如
<div onclick="doSomething()" ontouchstart="">；如果是原生button或a，通常不用额外加 - 不要和
touch-action: manipulation冲突使用——两者目的一致，混用不增效，反而可能干扰事件流 - SPA 路由切换后若动态插入新按钮，得确保这些新元素也带上
ontouchstart=""，否则新按钮照样延迟
真机测试时 :active 还是失效？先查这三件事
别急着改代码，先排除环境干扰。
- 关掉 Chrome DevTools 的 “Emulate touch” —— 它模拟不准，容易误判，真机连 USB 调试才能反映真实行为
- 检查元素是否被
pointer-events: none拦截，或父容器有遮盖层（比如绝对定位的空div盖在按钮上） - 确认没设
user-scalable=no却没配touch-action或空ontouchstart，这种组合会让 iOS 彻底禁用:active
真正麻烦的不是方案本身，而是不同 iOS 版本、微信 8.0.52 vs 8.0.60、QQ 浏览器内核更新后对 :active 的支持程度都可能变化——同一套代码，在 A 设备上 OK，在 B 设备上失效，得挨个真机点按验证。
