CSS动画性能优化核心是优先使用transform和opacity，因其由合成器线程处理、不触发重排重绘；避免top/left、width/height等会强制主线程计算的属性；慎用will-change，防止图层过多拖慢性能；动态场景下JS动画更灵活高效。
CSS 动画性能不一定总是优于 JS——当用错属性、建太多图层或硬套静态动画到动态场景时，它反而更耗资源。
哪些 CSS 动画属性会悄悄拖慢主线程
不是所有 transition 或 @keyframes 都走 GPU 加速。浏览器只对少数属性做合成层优化：
-
transform（含translate、scale、rotate）和opacity是安全的，触发硬件加速 -
top/left、width/height、box-shadow、filter（除blur外多数）仍走主线程，每次变化都强制重排+重绘 - 哪怕写了
transition: all 0.3s，只要动画过程中实际变更了top，性能就立刻掉档
will-change 和 translateZ(0) 不是万能加速开关
强行提升图层看似能“加速”，但代价常被忽略：
-
will-change: transform或transform: translateZ(0)会为元素新建合成层 - 单个元素加没问题；但批量加在列表项、轮播图每一帧上，GPU 内存压力陡增
- 图层过多导致上下文切换开销上升，实测中 20+ 合成层反而比 5 层时帧率更低
- 移动端尤其敏感：iPhone 上图层数超阈值后，动画掉帧+发热明显
JS 动画反而更省电的三种真实场景
CSS 动画时间轴固化，无法响应运行时状态。这时硬套 CSS，JS 反而更高效：
立即学习“前端免费学习笔记（深入）”；
- 用户拖拽中实时插值（如跟随光标、视差滚动）——
mousemove频繁触发，CSS 无法动态更新@keyframes - 需要中断/反向/跳转进度（比如播放器进度条拖动后立即跳到新位置）——
animation-play-state控制粒度太粗，还得靠 JS 强制重置 - 物理模拟类动画（如弹簧效果
spring(250, 20)或图表数值驱动位移）——CSS keyframes 是静态的，JS 才能每帧计算新值
真正容易被卡住的地方，不是“该不该用 CSS”，而是没判断清楚动画是否真的「静态可声明」。一旦涉及运行时数据、用户输入或条件分支，CSS 就得让位——这时候再堆 will-change 或换属性名，只是把问题从 CPU 转移到 GPU。
