真正省电需销毁动画并重置样式：移除动画类、强制reflow、清空transform/opacity/will-change，调用库的disable方法，避免终态样式引发隐式重排。
它不会——只要动画真的停了，就不会耗电。问题出在“你以为它停了，其实没停干净”，或者“停是停了，但停的方式本身就在耗电”。
animation-play-state: paused 不能让动画真正休眠
很多人用 JS 监听 visibilitychange，然后执行 el.style.animationPlayState = 'paused'，以为这就省电了。但这是错觉：
-
animationPlayState只控制播放/暂停状态，不释放图层、不卸载合成任务，GPU 仍保留该元素的独立合成层（compositor layer） - 若动画用了
animation-fill-mode: forwards，暂停后元素仍维持终态样式，浏览器无法判断是否可回收资源 - iOS Safari 对该属性 runtime 修改支持极弱，常出现“设了 paused，但 DevTools 里
getComputedStyle(el).animationPlayState仍是running”
后台未清理的 transform 或 will-change 持续占用 GPU 内存
即使动画已停，这些声明仍会让浏览器长期维持硬件加速图层：
-
transform: translateZ(0)或will-change: transform是“一次性建层”指令，不会因页面不可见而自动销毁 - 低端 Android 设备上，5 个以上此类元素就可能触发 GPU 内存压力，导致系统级降频或强制重绘
- 如果动画元素父容器有
overflow: hidden或transform，子元素的合成层可能被截断，浏览器被迫回退到 CPU 渲染——此时哪怕不动，也持续占着 CPU
JS 逻辑未同步停掉，间接唤醒主线程
CSS 动画停了，但配套的 JS 可能还在跑：
- 监听
animationend的回调未移除，事件队列中仍有待处理任务 - 用
requestAnimationFrame驱动状态轮询（比如检测滚动位置、计算视差偏移），即使页面不可见，RAF 在部分 WebView 中仍会低频触发 - 动画组件内部有定时器（
setInterval）或网络轮询（如心跳检测），它们和 CSS 动画无关，但共存于同一模块，容易被忽略
真正省电的做法：不是暂停，而是销毁 + 重置
后台时要做的不是“按暂停键”，而是“拔电源+清灰”：
- 监听
visibilitychange后，先el.classList.remove('animating')移除所有动画类 - 强制一次 reflow：
el.offsetHeight或getComputedStyle(el).opacity，确保样式引擎重新评估 - 清空内联
transform和opacity：el.style.transform = ''、el.style.opacity = '' - 移除
will-change：el.style.willChange = ''（注意不是none，设为none仍会建层） - 若用了第三方动画库（如 AOS），必须调用其
disable()方法，不能只靠 CSS 类控制
最容易被忽略的是：动画停掉后，元素的 transform 终态可能和布局流冲突（比如 translateY(-100px) 让它脱离文档流却没设 position: absolute），浏览器会持续做隐式修正计算——这种“静默重排”不报错、不卡帧，但 CPU 一直在动。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
