Firefox后台直接冻结CSS动画时间轴，非bug而是强制节电；需用class切换+offsetHeight强制reflow重播，且animation-fill-mode必须为none、duration≥150ms、清空内联transform。
Firefox 后台标签页会直接暂停 CSS 动画时间轴，不是 bug，是主动冻结；跨端同步和动画行为无关，别混淆——前者靠 Firefox 账户配对与开关控制，后者纯属浏览器渲染策略。
Firefox 后台暂停 CSS 动画是强制冻结，不是节流
Chrome/Edge 在后台会把 requestAnimationFrame 节流到约 1fps，而 Firefox 更彻底：失焦瞬间就冻结整个动画时间轴。此时 element.style.animationPlayState 仍返回 'running'，但 @keyframes 帧完全不计算、不合成。这不是卡顿，是合成线程直接让渡资源。
常见错误现象包括：
- 轮播图切回来直接跳到第 5 轮，中间 3 轮全丢失
- 倒计时显示“已过期”，实际只过去 2 秒
- DevTools 的 “Animations” 面板里动画进度条停在某处不动
原因很明确：Firefox 不依赖 visibility 状态做软节流，而是硬性挂起时间轴。你无法用 animation-play-state: running 恢复，它只会从冻结点继续跑。
立即学习“前端免费学习笔记（深入）”；
重播动画必须 class 切换 + offsetHeight 强制 reflow
想让用户切回时看到“新开始”的动画，不能靠 resume，得让它当做一个全新动画触发。核心是三步原子操作，缺一不可：
el.classList.remove('spin')-
void el.offsetHeight（关键！必须同步触发 layout） el.classList.add('spin')
同时确保动画类中声明：animation-fill-mode: none。若设了 forwards，浏览器会认为“已完成”，拒绝重播。另外，animation-duration 必须 ≥ 150ms，否则部分 Firefox 版本直接跳过首帧。
容易漏的坑：
- JS 曾设置过
el.style.transform，残留内联样式会和动画里的transform冲突，重播前务必清空：el.style.transform = '' - 仅监听
visibilitychange不够，iOS Safari 和微信 WebView 延迟严重甚至不触发，需同时绑定pageshow和focus
“跨端同步”和动画暂停完全无关，别混为一谈
CSS 动画是否运行，只取决于当前标签页是否可见；Firefox 多端同步“已打开的标签页”，靠的是设备可信配对 + 手动开启开关，和页面是否在后台毫无关系。
典型配置遗漏点：
- 手机 Firefox 设置里，“选择要同步的内容”中
已打开的标签页开关默认关闭，必须手动拨成蓝色 - 电脑和手机未完成可信配对：仅登录同账户不够，需扫码或输入 24 位同步密钥（输错一位即静默失败）
- 电脑端 Firefox 未保持活跃状态：同步要求桌面浏览器处于打开且非挂起状态，休眠或被系统终止后无法推送
验证是否生效：手机端点击菜单 → 邮箱地址 → 底部点 立即同步 → 返回后长按书签栏 → 选“从其他设备打开的标签页”。如果列表为空，问题一定出在配对或开关上，和 CSS 动画无关。
最易被忽略的复杂点：Firefox 的动画冻结是时间轴级的，意味着所有基于 animationiteration 或 animationend 的 JS 逻辑，在后台切回后都会失效或错位；而同步功能的延迟又常被误判为“动画没同步过来”。两者机制完全不同，排查时必须分开验证。
