必须用 requestAnimationFrame 的情况是 CSS 无法实现的动画：贝塞尔曲线+随机扰动的粒子运动、拖拽中动态参数的缓动回弹、需逐帧读取布局信息（如 getBoundingClientRect）、与 Web Audio 精确同步的音画帧对齐。
纯 CSS 动画在绝大多数场景下比 requestAnimationFrame 手写 JS 动画更优——它更省电、更流畅、更易维护，且天然支持硬件加速和浏览器优化。只有当动画逻辑依赖运行时数据（比如鼠标位置、滚动偏移、物理模拟）或需精确控制暂停/跳帧/动态插值时，才该用 requestAnimationFrame。
什么时候必须用 requestAnimationFrame
不是“想自定义就用”，而是被 CSS 能力卡住时的必要选择：
-
transform或opacity无法表达的运动逻辑，例如：粒子系统中每个点按贝塞尔曲线+随机扰动移动 - 动画状态需实时响应用户输入，例如：拖拽中跟随鼠标做缓动回弹，且回弹参数随拖拽距离动态变化
- 需要逐帧读取并修改 DOM 布局（如
getBoundingClientRect()），再基于结果决定下一帧行为——CSS 无法读取布局信息 - 与 Web Audio API 同步播放音效+视觉反馈，要求帧精度对齐（
requestAnimationFrame时间戳可与audioContext.currentTime对齐）
CSS 动画的隐藏性能陷阱
很多人以为加了 will-change: transform 就万事大吉，实际容易踩坑：
- 滥用
will-change：对非频繁变化的元素设置，反而触发不必要的图层提升和内存开销 - 动画属性选错：用
left/top触发重排（layout），而应始终用transform: translateX()和opacity - 过度嵌套动画：父容器设
animation，子元素又设独立动画，可能因图层合并失败导致掉帧 - 未关闭非必要动画：页面不可见时（
visibility: hidden或display: none）仍运行 CSS 动画，浪费 GPU 资源
验证方式：打开 Chrome DevTools → Rendering → 勾选 “FPS Meter” 和 “Paint Flashing”，观察是否持续高亮、帧率是否稳定在 60fps。
requestAnimationFrame 的正确写法和常见错误
直接调 requestAnimationFrame 不等于写出高性能动画。关键在避免强制同步布局和冗余计算：
function animate(lastTime) {
const now = performance.now();
const delta = Math.min(now - lastTime, 16); // 防止丢帧过大
// ✅ 在 rAF 回调里只做「读取」或「写入」，不要混用
const rect = element.getBoundingClientRect(); // 读取布局（仅此处）
// ✅ 所有样式更新集中到一次重排前完成
element.style.transform = translateX(${easeInOutCubic(delta / DURATION) * 100}px);
// ❌ 错误：在读取后又立即读取（触发二次 layout）
// element.offsetWidth; // 不要这样
if (isAnimating) {
requestAnimationFrame(animate);
}
}
- 永远用
performance.now()而非Date.now()，前者精度更高、不受系统时间调整影响 - 避免在回调中调用
getComputedStyle、offsetHeight等触发重排的 API，除非你明确需要当前布局快照 - 用
element.animate()（Web Animations API）替代手动requestAnimationFrame，它底层复用 CSS 动画引擎，支持时间轴控制且更省资源
真正难的不是选哪个 API，而是判断动画是否真的需要脱离 CSS 生命周期——多数所谓“复杂动画”，其实只是没拆解清「驱动源」和「表现层」。一旦把数据流（如 scrollY、mouseX）抽出来作为输入，渲染层依然可以交给 CSS。
