动画开cpu飙高主因是layout和paint：修改width/height/top/bottom等属性强制每帧重排重绘；应改用transform/opacity等仅触发composite的属性，并监听visibilitychange暂停后台动画。
为什么动画一开CPU就飙高？Layout和Paint是元凶
直接原因是动画修改了会强制触发浏览器 Layout（重排）和 Paint（重绘）的 CSS 属性，每帧都得在主线程里重算布局、重绘图层。这些操作无法跳过，哪怕只改 left: 1px，渲染树就得全量重走一遍。
常见高开销属性包括：width/height/top/bottom/left/right（配合 position: relative 或 absolute）、margin/padding/font-size/line-height、display/float。它们的共同点是：破坏了浏览器对合成层的缓存假设。
验证方式很简单：
打开 Chrome DevTools → Performance 面板 → 录制一段动画 → 看火焰图里 Layout 和 Paint 是否密集占满每帧。如果占比超过 30%，基本坐实是这些属性拖垮了帧率。
怎么把高开销动画改成低开销写法？只换属性，不改逻辑
核心思路是：用仅触发 Composite（合成）的属性替代 Layout/Paint 属性，让 GPU 接管动画关键路径。
-
left: 100px→ 改成transform: translateX(100px) -
top: 50px→ 改成transform: translateY(50px) -
width: 200px→ 改成transform: scaleX(2)，并加transform-origin: left center控制缩放起点 -
opacity: 0.5本身安全，但别和box-shadow或background: linear-gradient()叠加——Paint 开销会指数级上升
注意：translate3d(0, 0, 0) 虽能升层，但滥用会导致图层数失控、内存飙升；优先用 will-change: transform，且必须在动画开始前 1–2 帧动态添加，结束立即移除。
隐藏标签页里CPU还在狂飙？那根本不是CSS动画
CSS 动画（纯 @keyframes 或 transition）在标签页隐藏时，浏览器会自动暂停合成线程，CPU 几乎为 0。如果你发现隐藏后 CPU 仍高，说明实际跑的是 requestAnimationFrame 回调。
requestAnimationFrame 不感知页面可见性，只要没手动调用 cancelAnimationFrame，JS 线程就照常每秒执行约 60 次。更麻烦的是，Safari 和部分安卓 WebView 完全不节流后台 tab，像 getBoundingClientRect() 这类同步布局 API 在里面每调一次，都等于主动触发一次 Layout。
正确做法：
监听 document.visibilityState 或 visibilitychange 事件，在页面隐藏时暂停动画逻辑，显示时再恢复。
动画元素嵌套太深或用了太多 box-shadow？性能会雪崩
动画元素层级越深，合成时需处理的依赖关系越复杂；同时叠加多个高成本视觉效果（比如 box-shadow + filter: blur() + 渐变背景），Paint 区域会扩大、绘制频率升高，尤其在移动端极易卡顿。
优化建议：
把动画元素尽量提到 DOM 较浅层级（比如直接挂到 body 下）；
避免在滚动容器内给大量子项加 will-change；
如必须用阴影，可考虑用伪元素分离：把 box-shadow 提到 ::after 上，主元素只做 transform 动画；
慎用 filter，它几乎必然触发全量重绘，且无法被硬件加速。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
