根本原因是使用了触发Layout和Paint的CSS属性；应改用transform、opacity等仅走合成线程的属性，并配合visibilitychange事件控制动画启停，避免requestAnimationFrame后台运行及will-change滥用。
根本原因不是CSS动画本身，而是你用了会强制触发 Layout 和 Paint 的属性——比如 top、left、width、height、margin、padding，这些属性让浏览器每帧都得在主线程里重算布局、重绘图层。
哪些CSS属性会让动画吃掉CPU？
只要改了以下任一属性，浏览器就无法跳过 Layout 或 Paint 阶段：
-
top/left/right/bottom（尤其配合position: relative或absolute） -
width/height/margin/padding/font-size -
display、float、box-shadow（动画时）、filter（如blur()）
验证方式：打开 Chrome DevTools → Performance 面板 → 录制动画 → 看火焰图中 Layout 和 Paint 是否密集占满每帧。如果占比超 30%，基本就是它们在拖累。
怎么把高开销动画改成低开销写法？
核心是只用能走合成线程（compositor thread）的属性，让 GPU 接管关键路径：
-
left: 100px→ 改成transform: translateX(100px) -
top: 50px→ 改成transform: translateY(50px) -
width: 200px→ 改成transform: scaleX(2)，并加transform-origin: left center -
opacity本身安全，但别和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事件，在页面隐藏时暂停动画逻辑，显示时再恢复
容易被忽略的性能雪崩点
这些细节看似无关紧要，实则常导致动画突然卡顿或耗电激增：
- 动画元素嵌套太深（比如 8 层 div 套着动），合成依赖关系爆炸式增长
- 父容器有
overflow: hidden，子元素用transform: rotateZ(0deg)就可能回退到软件渲染 - 同时激活超过 100 个
will-change或硬件加速元素，iOS 设备可能直接崩溃 -
position: fixed元素上混用top和transform，浏览器可能放弃合成优化
真正难的不是换掉 left 改用 translateX，而是在复杂 DOM 结构、多层遮罩、响应式断点切换下，持续保证图层策略稳定不退化。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
