根本原因是iOS Safari和安卓WebView默认禁止非用户手势触发的自动播放，CSS动画受此策略约束；需双写@keyframes和animation并加前缀兼容旧版，但更关键的是用JS控制触发时机以绕过限制。
animation 在 iOS Safari 和部分安卓 WebView 里不触发自动播放
根本原因不是「没加 -webkit- 前缀」，而是 iOS Safari（13.4+）和多数安卓 WebView 默认禁止「非用户手势触发的音频/动画自动播放」——尤其是带 animation-play-state: running 且未显式调用 play() 的 CSS 动画。即使写了 @keyframes 和 animation，若页面一加载就期望它动，大概率静止。
必须加 -webkit-keyframes 和 -webkit-animation 吗？
在 iOS 15.4 之前，Safari 要求关键帧和动画属性都带 -webkit- 前缀才能识别；iOS 15.4+ 和 Chrome for Android 已基本支持无前缀写法，但兼容性仍需兜底：
-
@keyframes必须同时声明：@keyframes slide-in { to { transform: translateX(100px); } } @-webkit-keyframes slide-in { to { transform: translateX(100px); } } -
animation属性建议双写：animation: slide-in 0.3s ease-out; -webkit-animation: slide-in 0.3s ease-out;
- 只写
-webkit-版本而漏掉标准版，在新版 Chrome 或桌面 Safari 可能失效
为什么加了前缀还是不动？检查这三处硬限制
iOS 对「自动播放」有明确策略，CSS 动画受其约束，和视频、音频同级：
- 页面处于后台标签页时，
animation会被暂停（visibility: hidden或display: none状态下不渲染帧） - 页面刚加载完成时，若 DOM 尚未稳定（比如动画元素是 JS 动态插入的），Safari 可能跳过首帧
- 某些安卓 WebView（如微信内置 X5）会禁用
animation直到首次用户交互（tap/click），哪怕已加前缀 - 解决方案：延迟 1ms 触发或监听
DOMContentLoaded后强制重设动画：element.style.animation = 'none'; setTimeout(() => { element.style.animation = 'slide-in 0.3s'; }, 1);
更稳妥的替代方案：用 requestAnimationFrame + class 切换
绕过自动播放限制最可靠的方式，是放弃纯 CSS 触发，改用 JS 控制时机：
立即学习“前端免费学习笔记（深入）”；
- 初始状态用
opacity: 0; transform: translateX(-20px); - 在
DOMContentLoaded或scroll事件中添加类：element.classList.add('animate-in'); - CSS 中定义：
.animate-in { animation: slide-in 0.3s ease-out; } - 这样既避开自动播放策略，又保留硬件加速（
transform和opacity仍走合成层）
真正卡住的往往不是前缀漏没漏，而是把 animation 当成「只要写了就会动」的声明式逻辑，忽略了移动端对资源调度的主动干预。动手前先确认：这个动画是否真需要「零交互启动」？如果不是，加个轻量级点击触发反而更稳。
