requestAnimationFrame 更适合动画因其与屏幕刷新率同步、自动暂停省电、需配合时间戳防速度不均;CSS transition 适合简单属性变化,而 requestAnimationFrame 适合复杂交互控制。
因为

requestAnimationFrame 与屏幕刷新率同步(通常 60fps),不会出现丢帧或卡顿;而 setTimeout 的执行时机不可控,容易累积延迟,尤其在页面后台运行或 CPU 压力大时帧率骤降。
requestAnimationFrame 自动暂停,省电且不浪费资源能,但必须分清职责:CSS transition 适合简单、状态明确的属性变化(如颜色、尺寸、透明度);requestAnimationFrame 适合需要逐帧控制逻辑的动画(如物理模拟、滚动跟随、多属性异步变化)。
transform 和 transition,再用 JS 改变 style.transform,会触发 CSS 过渡——此时 requestAnimationFrame 反而多余,还可能干扰过渡时序requestAnimationFrame + transform,禁用 transition,否则样式冲突会导致跳变getComputedStyle(el).transform 读取当前矩阵时,不要在 requestAnimationFrame 回调里频繁读取——会强制同步布局,严重拖慢性能核心是用时间戳算出已过去比例 t,再代入缓动函数(如 easeOutQuad),避免固定步长导致的精度丢失和终点偏差。
function animateTranslate(el, fromX, toX, duration = 300) {
const start = performance.now();
const deltaX = toX - fromX;
function step(now) {
const elapsed = now - start;
const t = Math.min(elapsed / duration, 1); // 归一化时间 [0, 1]
const eased = 1 - (1 - t) (1 - t); // easeOutQuad
const x = fromX + deltaX eased;
el.style.transform = `translateX(${x}px)`;
if (t < 1) {
requestAnimationFrame(step);
}}
requestAnimationFrame(step);
}
performance.now(),不用 Date.now(),前者精度更高(微秒级),避免长时间运行后误差累积Math.min(elapsed / duration, 1) 防止因帧率抖动导致 t > 1,造成过冲transform,保留最终状态;如需复用,应显式清理内联样式或使用 CSS 自定义属性驱动多数不是 API 本身问题,而是 JS 主线程被阻塞或样式操作不当。
requestAnimationFrame 回调里执行大量 DOM 查询(如 offsetTop、getBoundingClientRect)、修改 class 或触发 layout —— 立即引发强制同步重排transform: translateZ(0) 或 will-change: transform 可让浏览器提前分配合成层,但滥用会导致内存占用升高scroll 或 resize 并直接在里面调用 requestAnimationFrame,却没做节流,导致回调堆积innerHTML 或频繁 appendChild 更新动画容器内容,会打断渲染流水线复杂交互动画建议把计算逻辑移到 Web Worker,只在主线程做 transform 更新;CSS 层面优先用 transform 和 opacity,这两者可由合成器单独处理,不触发布局和绘制。