浏览器后台冻结css动画是节电策略，animation-play-state无法重播；可靠重播需class切换+同步reflow（如offsetheight）+清除干扰样式。
浏览器标签页切到后台时 CSS 动画自动停止，不是 bug，是所有主流浏览器（Chrome、Firefox、Safari、Edge）主动冻结渲染管线的节电策略。你无法靠 animation-play-state “唤醒”它——它只会从冻结时刻继续，而不是重播。
为什么直接设 animationPlayState = 'running' 没用
常见错误现象：监听 visibilitychange 后立刻写 el.style.animationPlayState = 'running'，但动画没重播，甚至完全没反应。
-
animation-play-state只控制播放/暂停状态，不重置时间轴；后台停留 15 秒，回来后就从第 15 秒接着走 - iOS Safari（尤其微信 WebView）对 runtime 修改
animationPlayState支持极差，常忽略或延迟生效 - 若动画已因
animation-fill-mode: forwards停在终态，再设running不会触发新周期——它“已完成”了 -
getComputedStyle(el).animationPlayState可能仍返回"running"，但实际帧早已冻结
可靠重播必须用 class 切换 + 强制 reflow
真正起作用的做法是让浏览器“认为这是一个新动画”，而不是试图恢复旧动画。
- 把动画逻辑封装进独立类，例如
.animate-bounce，只含animation和animation-fill-mode: none（避免forwards干扰重播） - 初始状态用另一个类控制，如
.is-hidden，确保元素不可见时无任何 animation 声明 - 监听
visibilitychange，当document.visibilityState === 'visible'时：- 先移除动画类：
el.classList.remove('animate-bounce') - 强制同步 reflow：
el.offsetHeight或getComputedStyle(el).opacity - 再添加动画类：
el.classList.add('animate-bounce')
- 先移除动画类：
移动端和 iOS Safari 的兼容性陷阱
这些细节不处理，class 切换也会失效：
- iOS Safari 对
visibilitychange响应常延迟 200–500ms，建议加setTimeout(() => { /* class 切换 */ }, 100) - 如果元素有内联
style.transform（比如 JS 设置过位移），再通过 CSS 类触发带transform的动画，两者会冲突导致跳帧或不触发；重播前可临时清空：el.style.transform = '' - 动画时长低于
0.15s（150ms）时，部分 Android Webview 会跳过首帧；最低建议设为0.15s - 不要依赖单个事件：同时监听
visibilitychange、pagehide、pageshow、focus，任一触发都尝试重置
别碰 backface-visibility 或 animation-fill-mode: forwards 来解决后台停止
这两个属性和后台冻结完全无关：
-
backface-visibility: hidden只影响动画过程中的图层稳定性（比如 Safari 白边抖动），对“是否运行”无任何控制力 -
animation-fill-mode: forwards解决的是动画结束后“闪回原位”，不是后台暂停；它甚至会让重播更难——因为终态已锁定，class 切换后需先清除终态样式才能重播 - 如果你的动画本就依赖
forwards锁定终态，重播前得额外清理：移除类 → reflow → 清空内联 transform/opacity → 再加类
最易被忽略的一点：reflow 必须是同步的，el.offsetHeight 是最轻量可靠的触发方式；用 setTimeout 或 requestAnimationFrame 包裹 reflow 就失去意义——浏览器不会在异步时机重新计算动画实例。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
