css动画在隐藏页会被浏览器暂停，cpu无负担；而requestanimationframe不会自动感知可见性，需手动结合document.hidden和visibilitychange控制启停。
隐藏标签页时 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 创建
<style></style>标签并注入@keyframes，若插入时机在页面已隐藏后，部分旧版 Android WebView 可能不暂停，需手动控制animation-play-state - 与 JS 交互的动画：例如用
element.animate()启动的动画，它返回的是Animation对象，必须显式调用animation.pause()，否则即使页面隐藏也不会停 -
will-change: transform配合动画时，若元素在隐藏状态下仍保持该声明，某些浏览器会维持合成层，虽不耗 CPU，但多占 GPU 内存，长期驻留可能影响后续动画创建
真正决定 CPU 是否升高的，从来不是“有没有动画”，而是“有没有持续执行的 JS 逻辑”——哪怕只是一行 console.log 套在 requestAnimationFrame 里，切后台后也照样拉高 CPU。别假设浏览器会替你兜底，可见性控制必须由你亲手写进代码里。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
