不能改用 requestanimationframe 解决 css 动画隐藏页暂停问题，因其同样受 visibility 状态节流；需根据场景选型并手动处理 visibilitychange 事件与动画生命周期。
直接说结论：不能“改用 requestAnimationFrame”来解决 CSS 动画在隐藏页停止的问题——因为这是两个完全不重叠的机制，且问题本身被误解了。
为什么“改用 RAF”不是解决方案
CSS 动画在标签页隐藏时暂停，是浏览器主动冻结合成线程的结果，属于性能优化行为；而 requestAnimationFrame 是 JS 运行时 API，它在页面隐藏时也会被节流或暂停（Chrome/Edge 约 1fps，Safari 可能不节流）。两者都受 visibility 状态影响，不存在“RAF 能动而 CSS 不能动”的差异。
常见误判场景：
- 看到 CSS 动画停了，以为 JS 动画还能跑，结果发现
requestAnimationFrame回调也卡住或变慢 —— 实际是没加document.hidden判断，或没做cancelAnimationFrame清理 - 用
element.animate()启动动画后切后台，动画继续跑 —— 这是因为该 API 返回的Animation对象未被显式pause()，和 CSSanimation-play-state无关 - 误以为“CSS 停了所以得换 JS”，但没意识到：纯 CSS 动画在隐藏页 CPU 几乎为 0，而手写 RAF 若不控制可见性，反而可能持续吃 CPU
真正要区分的是：你到底需要什么
选型取决于目标，不是“哪个不停就用哪个”：
- 只做 UI 状态切换（如按钮 hover、加载 spinner）→ 用 CSS
@keyframes+animation，轻量、硬件加速、自动暂停 - 需精确帧控制、动态插值、多对象协同（如数据可视化、游戏）→ 用
requestAnimationFrame，但必须手动处理visibilitychange - 需 JS 触发 + CSS 执行 → 混合方案：JS 控制 class 切换，CSS 定义动画，监听
animationend回调
注意：element.animate() 属于 Web Animations API，它既不是纯 CSS 也不是传统 RAF，但其返回的 Animation 对象必须显式 pause() / play()，否则页面隐藏也不会停。
如何让 requestAnimationFrame 在页面切换时可靠工作
关键不在“替换”，而在“补全控制逻辑”。以下为最小可行实践：
- 启动前检查：
if (!document.hidden) rafId = requestAnimationFrame(animate) - 监听切换：
document.addEventListener('visibilitychange', () => { if (document.hidden) cancelAnimationFrame(rafId); else rafId = requestAnimationFrame(animate); }) - 回调内加
try...catch，防止某帧报错导致整条 RAF 链断裂 - 避免在回调中访问已移除 DOM 或未就绪资源（如
img.naturalWidth === 0时调用绘图） - 时间戳用
performance.now()，但页面恢复时需重置起始时间，否则 delta 过大会导致缓动函数异常
CSS 动画真的一点都不能“续播”吗
不能靠 animation-play-state 续播，但可以“伪续播”：
- 隐藏前记录
getComputedStyle(el).animationDuration和已运行时间（用performance.now()打点） - 恢复时计算应跳转到的进度：
currentTime = (elapsed % duration) - 用
el.animate(keyframes, { ... })创建新动画实例，并设startTime或用currentTime强制起始位置 - 更轻量做法：
el.style.animation = 'none'; el.offsetHeight; el.style.animation = originalValue;（强制重播）
这些操作都绕不开 JS 主动干预 —— 浏览器不会帮你记进度，也不会在标签页恢复时自动重算时间线。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
