浏览器冻结非活跃标签页的requestanimationframe、css动画计时器并降低定时器精度；切回时需手动计算帧位置或重置动画class，will-change无效，ios safari还可能释放gpu图层。
切换标签页后 CSS 动画不同步或卡顿，不是动画写错了，而是浏览器主动冻结了非活跃标签页的 requestAnimationFrame 和 CSS 动画计时器——这是所有现代浏览器的默认行为，目的是省电和保性能。
浏览器对非活跃标签页的动画做了什么？
Chrome、Firefox、Safari 等主流浏览器在标签页失焦（visibilitychange 事件触发）后，会做三件事：
- 暂停所有
requestAnimationFrame回调（JS 动画直接停） - 暂停 CSS
@keyframes动画的播放计时器（animation-play-state不会变，但时间轴冻结） - 降低定时器精度（
setTimeout/setInterval最小间隔被拉长到 1000ms）
这意味着：一个正在运行的 animation: spin 2s linear infinite，切走再切回来时，可能卡在中间帧、跳到下一周期起点，甚至因计时器漂移导致多个动画错相。
如何检测并恢复动画状态？
不能依赖 animationend 或单纯监听 visibilitychange 后重播——因为动画可能根本没播完就被冻住，animationend 根本不会触发。
- 用
document.hidden判断当前是否失焦，配合performance.now()记录最后更新时间 - 在
visibilitychange事件中，若document.visibilityState === 'visible'，手动计算“应播放到哪一帧” - 对关键动画元素，用
getComputedStyle(element).animationPlayState检查是否真在运行（返回running才可信） - 更稳妥的做法：切回时清空并重新添加动画 class，避免状态残留：
element.classList.remove('animate-spin'); element.offsetHeight; element.classList.add('animate-spin');（offsetHeight强制重排以重置动画）
为什么加了 will-change: transform 也没用？
will-change 只影响图层合成策略，不改变计时器冻结行为。它解决的是“动画执行时卡”，而标签页切换导致的是“动画压根没执行”。常见误判场景：
- 动画看起来“卡在半路”，其实是被冻结后切回瞬间强行续播，GPU 没来得及插值补帧
- 多个元素使用相同
@keyframes名称，但失焦期间各自动画进度不一致，切回后相位错乱 - 用
animation-delay实现轮播节奏，失焦后所有延迟重置，切回时集体爆发式播放
真正要处理的不是渲染，是时间逻辑——把动画从“绝对时间驱动”改成“相对帧驱动”，或干脆在失焦时暂停动画、切回时从头播。
移动端 Safari 的额外陷阱
iOS Safari（尤其 iOS 16–17）在后台标签页不仅冻结动画，还会释放 GPU 图层。切回时若元素仍带 will-change: transform，可能因图层重建失败导致首帧白屏或闪动。
- 失焦时主动清除
will-change：element.style.willChange = 'auto'; - 切回后延时 1 帧再设回：
requestAnimationFrame(() => { element.style.willChange = 'transform'; }); - 避免对
body或全屏容器设will-change，iOS 下极易引发整页图层销毁
最易被忽略的一点：prefers-reduced-motion 在标签页切回时可能动态生效，尤其 macOS/iOS 用户开启“减少运动”后，浏览器会在切回瞬间强制禁用所有动画——这时连 animation-play-state: running 都会被覆盖，必须用媒体查询兜底。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
