移动端CSS过渡失效主因是属性不可合成、未启硬件加速、层叠上下文截断及touch事件延迟；应优先用transform/opacity、加translateZ(0)、touchstart即时触发、≤0.2s短时长并降级适配低性能设备。
移动端 CSS 过渡失效的常见原因
直接在移动端写 transition: all 0.3s 却没反应？大概率不是代码错，而是触发条件不满足。iOS Safari 和部分安卓 WebView 对 transition 的触发有隐式限制：非“可合成层”属性（如 width、height、margin）在重排（reflow）后无法平滑过渡；更关键的是，很多元素默认没有开启硬件加速，导致过渡被降级为软件渲染，卡顿或直接跳变。
- 确保过渡属性是可合成的——优先用
transform和opacity，避免动left/top或background-color（后者在低端机上易掉帧） - 强制开启合成层：
transform: translateZ(0)或will-change: transform（注意别滥用，will-change会持续占 GPU 资源） - 检查是否被
overflow: hidden或父级transform截断了层叠上下文，导致子元素过渡被剪裁或禁用
touchstart 时立即触发动画而非 wait for click
移动端 click 有约 300ms 延迟，如果等 :active 或 click 再启动过渡，用户会明显感到滞后。正确做法是在 touchstart 阶段就添加类、触发 transform 变化，再用 touchend 恢复——这才能做到“手指一按就动”。
.btn {
transition: transform 0.15s cubic-bezier(0.25, 0.46, 0.45, 0.94);
}
.btn:active,
.btn.touched {
transform: scale(0.96);
}
- 用 JavaScript 监听
touchstart添加touched类，touchend/touchcancel移除，避免依赖伪类的兼容性问题 - 不要只监听
click：某些安卓浏览器在快速连点时可能吞掉第二次click，但touchstart几乎总能捕获 - 过渡时间建议 ≤ 0.2s，过长会削弱响应感；缓动函数推荐
cubic-bezier(0.25, 0.46, 0.45, 0.94)（类似 iOS 原生弹性）
适配不同 DPR 和滚动场景下的过渡表现
高 DPR 屏幕（如 iPhone 14 Pro 的 3x）本身不直接影响 CSS 过渡逻辑，但会放大渲染压力；更麻烦的是滚动中触发过渡——Safari 在 scroll 期间会暂停非合成属性的动画，甚至丢弃部分帧。
- 对滚动中需响应的元素（如吸顶导航），改用
position: sticky+transform位移，而不是靠 JS 改top值 - 避免在
scroll事件里频繁增删 class 触发过渡；改用IntersectionObserver或节流后仅在临界点操作 - 针对低性能设备（如旧款 iPad 或千元安卓机），可用媒体查询降级：
@media (max-width: 768px) and (prefers-reduced-motion: reduce)中关闭transition或设为transition: none
transitionend 事件在移动端的坑与替代方案
transitionend 在 iOS Safari 中常不触发——尤其当过渡被中断（如快速连续 toggle 类）、或元素被隐藏（display: none）后又恢复时。它也不区分前缀，webkitTransitionEnd 和标准事件需同时监听，且顺序不可靠。
立即学习“前端免费学习笔记（深入）”；
- 不要依赖
transitionend来做状态清理（如移除 loading 类），改用setTimeout+ 过渡时长（加 50ms 容错）更稳 - 若必须精确同步，用
requestAnimationFrame配合getComputedStyle检查transform值是否稳定，但成本高，仅限关键路径 - 更推荐声明式控制：用 CSS 自身完成闭环，例如用
@keyframes+animation替代多步transition，并用animation-fill-mode: forwards锁定终态
真正难的不是写过渡，而是判断什么时候不该用过渡——比如表单输入框聚焦时的缩放，可能干扰软键盘弹出；或者列表项滑动删除，一旦过渡卡住，用户手势就失焦了。这些地方宁可去掉动画，也不能留半截效果。
