CSS3动画在仅使用transform和opacity且无需运行时干预时性能更优，因其交由合成器线程处理、不触发重排重绘；JS动画虽控制灵活但受限于主线程，易因计算或DOM操作导致丢帧。
CSS3动画在性能上确实普遍优于JS动画，但这个“优”只在特定条件下成立——关键不是“谁更强”，而是“谁更适合当前任务”。直接说结论：当动画只涉及 transform 和 opacity，且无需运行时干预时，CSS3动画几乎总是更稳、更省资源。
为什么CSS3动画能绕过主线程重排重绘
CSS3动画（尤其是用 transition 或 @keyframes 配合 transform/opacity）会被浏览器识别为“可合成层变更”，从而交由 compositor thread（合成器线程）处理。这意味着：
- 不触发 layout（重排）或 paint（重绘），只做合成（composite）
- 即使主线程正忙于执行大量 JS，动画仍能以 60fps 持续运行
- GPU 可直接参与变换计算，CPU 负担大幅降低
而 JS 动画哪怕只改 element.style.transform，也得走主线程：读样式 → 计算 → 写样式 → 触发重绘/合成调度。一旦中间夹杂了 offsetWidth、getComputedStyle 或频繁 DOM 查询，丢帧几乎是必然的。
JS动画无法避免的性能硬伤
JS 动画的瓶颈不在代码写得有多“优雅”，而在执行模型本身：
立即学习“前端免费学习笔记（深入）”；
-
setTimeout/setInterval无法对齐屏幕刷新节奏，容易跳帧或卡顿 - 即使用
requestAnimationFrame，它也只是“告诉主线程下一帧该干活了”，并不能把动画逻辑移出主线程 - 每次回调中若做复杂计算（比如贝塞尔插值 + 多元素联动），会直接挤压其他任务时间
- 修改非合成属性（如
left、width、backgroundColor）会强制触发 layout + paint，开销呈指数增长
一个典型反例：element.style.left = x + 'px' 比 element.style.transform = 'translateX(' + x + 'px)' 慢数倍——前者触发重排，后者只走合成管线。
哪些场景下CSS3动画反而更慢或不可行
别被“CSS更快”的说法带偏。以下情况 CSS3 不仅没优势，还可能拖累体验：
- 需要根据鼠标位置实时插值（如视差滚动）：CSS 无法读取
event.clientX，必须用 JS - 动画中途要暂停、倒放、跳转到 73% 进度：CSS 的
animation-play-state只能启停，animation-delay不能动态重设 - 多个元素需按数据流联动（如图表数值变化带动柱状图高度+颜色+阴影同步动）：CSS 无法响应 JS 数据状态，硬套
@keyframes会导致 class 切换爆炸、维护成本飙升 - 旧版 Safari（iOS 12 及更早）对
will-change: transform处理异常，反而引发内存泄漏或闪烁
这时候强行用 CSS 实现，往往要靠 hack（比如用 JS 控制 class 切换模拟进度），结果比直接用 JS + requestAnimationFrame 还慢、还难 debug。
真正容易被忽略的点是：性能差异从来不是“CSS vs JS”的二选一，而是“能否让浏览器把工作分到对的线程”。很多开发者调了 transform 还卡，是因为同时改了 border-radius 或触发了 filter: blur() ——这些属性照样走主线程 paint。动画是否高效，取决于你动的是哪几个属性，而不是你写了 CSS 还是 JS。
