为什么CSS动画在切换后台后停止运行，Animation-play-state如何控制？

本文共计693个文字，预计阅读时间需要3分钟。

不是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