动画在浏览器后台时暂停是正常节电行为，非bug；应通过class切换强制重置重播，而非修改animationPlayState，注意iOS Safari延迟及transform冲突等兼容性问题。
动画在浏览器切到后台时自动暂停是正常行为
不是 bug，是浏览器主动节电策略。所有主流浏览器（Chrome、Firefox、Safari、Edge）在标签页不可见或进程进入后台时，会将 animation 和 requestAnimationFrame 暂停执行，以降低 CPU/GPU 占用。此时 animation-play-state 的计算值仍为 running，但实际帧不再渲染——你看到“停止”，其实是浏览器冻结了时间轴。
不能依赖 visibilitychange 事件直接 resume 动画
很多人试图监听 visibilitychange 并手动设 element.style.animationPlayState = 'running'，但这样常无效，原因有三：
-
animation-play-state: running只恢复播放状态，不重置已流逝的时间；若后台停留 20 秒，回来后动画会从第 20 秒位置继续，而非从头播 - 部分浏览器（尤其是 iOS Safari）对
animation-play-state的 runtime 修改支持不稳定，尤其在页面刚唤醒时 - 如果动画已因
animation-fill-mode: forwards停在终态，再设running不会重新触发——它已“完成”了
可靠重启动画的实操方案
真正可落地的做法是：**用 class 切换强制重置并重播**，而不是试图“恢复”原动画。关键点：
- 把动画逻辑封装在独立类中（如
.animate-in），该类只含animation声明和必要animation-fill-mode - 初始状态用另一个类控制（如
.is-hidden），确保元素在不可见时无动画属性 - 监听
visibilitychange，当document.visibilityState === 'visible'时：
→ 先移除动画类（el.classList.remove('animate-in')）
→ 强制 reflow（el.offsetHeight或getComputedStyle(el).opacity）
→ 再添加动画类（el.classList.add('animate-in')） - 避免在
visibilitychange中直接操作style.animationPlayState，它不解决重播问题
容易被忽略的兼容性细节
某些场景下即使按上述流程操作，动画仍不重播：
- iOS Safari（尤其微信内置浏览器）对
visibilitychange响应延迟明显，建议加setTimeout(..., 100)延迟触发 class 切换 - 如果动画依赖
@keyframes中的transform，而元素本身有内联style.transform，两者会冲突导致重播失败；应统一用 CSS 类管理 transform 状态 -
animation-duration小于 100ms 时，部分 Android Webview 可能跳过首帧；建议最低设为0.15s
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
