移动端:active“看不见”是因浏览器限制触发时机：iOS Safari延迟/跳过非可交互元素，Android Chrome需绑定事件或设cursor:pointer；解决需加touch-action: manipulation、确保可交互语义、避免滚动中断，并优先用JS接管状态。
为什么移动端:active经常“看不见”
不是代码写错了，是浏览器主动限制了:active的触发时机。iOS Safari 为防止误触滚动，默认延迟或跳过非可交互元素的:active；Android Chrome 虽稍好，但若元素没绑定事件、没设cursor: pointer，照样不响应。
常见错误现象包括：a:active在WebView里完全没反应、div加了:active却始终不变色、真机测试时点一下就闪退样式——这些都不是CSS语法问题，而是语义和平台策略不匹配。
- 触发窗口极短：iOS上通常仅100ms左右，且只在手指按住未移动时生效
- 依赖可交互语义：原生
button、a默认支持，div必须加role="button"和tabindex="0" - 会被滚动中断：手指刚触屏就滑动，
:active状态立刻被取消
如何让:active在移动端真正生效
核心是告诉浏览器：“这个区域只用来点，别犹豫。”最轻量有效的做法是加touch-action: manipulation，它会禁用300ms延迟、提前激活点击态，并让:active更可靠。
实操建议：
立即学习“前端免费学习笔记（深入）”；
- 对目标元素（如列表项）直接设置
touch-action: manipulation - 确保父容器没设
pointer-events: none或overflow: hidden截断touch区域 - 给
div类按钮加tabindex="0"，否则部分Android机型根本不识别激活态 - 避免在
touchstart里调用event.preventDefault()，除非你真要禁滚动
:active和:focus在移动端不能混用
:active是瞬时态，松手即消失；:focus是持续态，焦点不移走就一直挂着。误把:focus当按下反馈，会导致按钮“卡在按下去”的错觉。
更麻烦的是：很多项目写button:hover, button:focus { ... }，结果iOS首次点击只触发:focus，样式卡住，再点才响应——这不是bug，是伪类语义错配。
-
:active适合模拟物理按压感（如transform: scale(0.98)） -
:focus只该用于键盘导航或明确需要持久高亮的场景 - 若需“点击后保持选中”，必须用JS切换
is-active类，而非依赖任一伪类
比:active更稳的替代方案
纯CSS的:active在复杂列表里极易失效，尤其含图片、图标或嵌套链接时。最可靠的方式是用JS手动控制状态：
监听touchstart加is-pressed，再在touchend、touchcancel里移除——这样能避开所有平台差异，且响应更快。
- 必须监听
touchcancel，否则手指滑出区域后状态残留 - 不要用
click代替touchstart，它有300ms延迟，且无法捕捉“按住”过程 - 搭配
transition做微动画，比如background-color 0.1s ease，视觉更自然
真正难的不是写几行CSS，而是判断什么时候该放弃:active、改用JS接管——尤其当列表项内有可滚动区域、或用户可能快速滑动时，硬撑:active只会增加调试成本。
