CSS动画卡顿？巧用requestAnimationFrame优化性能

CSS动画在页面隐藏时会被浏览器自动暂停，几乎不消耗CPU资源，而requestAnimationFrame却不会感知页面可见性，若未手动控制启停，后台仍可能以60fps持续执行，尤其在Safari和部分安卓WebView中毫无节流，极易引发CPU飙升；真正影响性能的并非动画本身，而是未加防护的JS执行逻辑——必须主动监听visibilitychange事件、结合document.hidden状态管理动画生命周期，否则哪怕一行console.log都可能拖垮后台标签页性能。

隐藏标签页时 CSS 动画不会升高 CPU，但 requestAnimationFrame 会——这是关键分水岭。浏览器对纯 CSS 动画（transform、opacity）做了深度优化：标签页不可见时，直接暂停合成线程调度，CPU 几乎无负担；而 requestAnimationFrame 是 JS 运行时机制，它不自动感知页面可见性，只要回调注册了，就照常执行。

为什么 requestAnimationFrame 在后台仍运行

它本质是浏览器向 JS 引擎发出的“下一帧请执行”的信号，不绑定 DOM 可见状态。即使页面切到后台、动画元素被 display: none 或 visibility: hidden，只要 requestAnimationFrame 回调没被显式取消，JS 线程就会持续调用它。

• 典型错误写法：function animate() { update(); requestAnimationFrame(animate); } —— 没做任何可见性判断，切后台后仍在每秒执行 60 次
• Chrome 和 Edge 会节流后台 tab 的 requestAnimationFrame 到约 1fps，但 Safari 和部分安卓 WebView 完全不节流，仍按 60fps 跑
• 如果动画逻辑里有 getBoundingClientRect() 或 offsetTop，每次调用都强制触发同步布局计算，CPU 压力翻倍

如何让 requestAnimationFrame 智能暂停

必须手动监听页面可见性，而不是依赖浏览器“可能节流”。核心是结合 document.hidden 和 visibilitychange 事件。

• 启动前检查：if (!document.hidden) requestAnimationFrame(animate);
• 监听切换：document.addEventListener('visibilitychange', () => { if (document.hidden) cancelAnimationFrame(rafId); else rafId = requestAnimationFrame(animate); });
• 避免在 visibilitychange 回调里直接调用 requestAnimationFrame，应加一层防抖或状态锁，防止快速切换时反复启停

CSS 动画在隐藏页真的完全安全吗

绝大多数情况下是的，但有两个例外场景容易被忽略：

• 动态插入的 CSS 动画：比如通过 JS 创建