JS动画核心是requestAnimationFrame，它同步屏幕刷新率实现60fps平滑动画；应操作transform和opacity等合成属性避免重排，CSS动画适合简单状态切换，JS动画适合动态交互控制。
JS动画的核心是requestAnimationFrame
浏览器原生支持的 requestAnimationFrame 是实现平滑JS动画的唯一推荐方式。它让动画帧率与屏幕刷新率同步（通常60fps），避免 setTimeout 或 setInterval 造成的丢帧和卡顿。
常见错误是直接操作 style.left 或 style.top 配合定时器——这会强制同步布局计算，性能极差；现代做法应统一用 transform: translateX() 等合成属性，并配合 will-change: transform 提前提示浏览器。
示例：一个向右平移200px的元素
translateX(${x}px)
CSS动画适合状态切换，JS动画适合动态控制
CSS动画（@keyframes + animation）本质是声明式：你定义起点、终点和缓动，浏览器负责执行。它轻量、硬件加速好、内存占用低，但无法在运行时精确控制进度、暂停、反向或响应数据变化。
JS动画是命令式：你可以随时读取当前位移、根据鼠标位置实时调整速度、在碰撞时中断并触发物理反弹——这些在纯CSS里要么做不到，要么要靠hack（如反复增删class、操纵 animation-play-state）。
- 用CSS：按钮悬停缩放、加载指示器旋转、页面淡入淡出
- 用JS：滚动视差、拖拽跟随、数据图表过渡、游戏内角色移动
性能差异关键看是否触发重排（reflow）
无论CSS还是JS，只要修改了影响布局的属性（如 width、height、top、left），都会触发重排+重绘，性能崩塌。真正高性能的动画只应操作以下几类属性：
- CSS侧：仅
transform（translate/scale/rotate）和opacity - JS侧：只通过
element.style.transform和element.style.opacity修改 - 避免：所有涉及盒模型计算的属性，包括
margin、padding、border、font-size
注意：即使用了 transform，若元素未启用GPU加速（例如父容器有 transform: none 或 overflow: hidden 干扰层叠上下文），仍可能退化为CPU渲染。
兼容性与维护成本不能只看“哪个更快”
CSS动画在IE10+、Safari 9+、Chrome 43+ 均稳定支持；requestAnimationFrame 在IE10+也已覆盖，但旧安卓WebView（4.3及更早）需polyfill。真正差异在于可维护性：
- CSS动画逻辑分散在样式表中，调试靠DevTools时间轴，难以注入业务逻辑
- JS动画逻辑集中，可加断点、打日志、接入状态机（如
anime.js或gsap），适合复杂交互动画 - 混合使用很常见：用CSS做基础转场（
transition: opacity .2s），用JS控制触发时机和参数
别纠结“哪个更优”，先问清楚：这个动画是否需要响应用户输入？是否依赖实时数据？是否要与其他逻辑耦合？答案决定技术选型，而不是基准测试数字。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
