因为setTimeout/setInterval不与屏幕刷新同步，易掉帧卡顿且后台仍运行；requestAnimationFrame则按刷新节奏执行、提供精准时间戳、需递归调用，并适合需JS实时干预的动画场景。
为什么不用 setTimeout 或 setInterval 做动画
因为它们不和屏幕刷新节奏同步，容易掉帧、卡顿，甚至在页面不可见时还在跑，浪费 CPU。浏览器每秒刷新约 60 次（即 16.67ms 一帧），而 setTimeout(fn, 16) 只是“尽量”隔 16ms 执行，并不能保证准时——实际执行时间受任务队列、JS 主线程阻塞影响很大。
- 动画逻辑可能被延迟到下一帧甚至更晚，造成视觉撕裂或跳变
- 标签页切到后台时，多数浏览器会把
setTimeout降频到 1s 以上，但动画仍会“假性运行”，恢复时疯狂补帧 - 无法获知当前帧的精确开始时间，难以做时间差校准（比如 easing 计算）
requestAnimationFrame 怎么用才对
它不是“启动一次就完事”的函数，而是一个需要手动递归调用的机制：每次回调执行完，如果还想继续动画，就得再调一次 requestAnimationFrame。
function animate(timestamp) {
// timestamp 是该帧开始时的高精度时间戳（DOMHighResTimeStamp）
const elapsed = timestamp - startTime;
element.style.transform = `translateX(${easeInOutCubic(elapsed / duration) * 200}px)`;
if (elapsed < duration) {
requestAnimationFrame(animate); // 关键：主动续订
}
}
let startTime = performance.now();
requestAnimationFrame(animate);
-
timestamp参数比Date.now()更准，且不受系统时间修改影响 - 不要在回调里直接写
element.style.left = ...，优先用transform，避免触发重排（reflow） - 如果动画要暂停/取消，需保存
requestAnimationFrame返回的 ID，并调用cancelAnimationFrame(id)
相比 CSS 动画，requestAnimationFrame 适合什么场景
CSS 动画声明式、性能好，但控制粒度粗；requestAnimationFrame 适合需要 JS 实时干预的动态过程。
- 鼠标跟随、拖拽反馈、滚动视差等依赖用户输入的动画
- 物理模拟（如弹簧、碰撞）需要每帧计算位置加速度
- 动画过程中要读取 DOM 尺寸或样式（比如根据容器宽度动态调整动画参数）
- 需要精确控制播放/暂停/倒放/跳转到某一进度（CSS
animation-play-state和animation-delay都不够灵活）
容易忽略的兼容性与陷阱
现代浏览器都支持 requestAnimationFrame，但它的行为细节常被低估。
立即学习“Java免费学习笔记（深入）”；
- 在 iOS Safari 中，如果页面有
overflow: scroll的容器，快速滚动时可能触发requestAnimationFrame被节流，导致动画“卡住”——此时可监听scroll事件 +passive: false，或改用IntersectionObserver触发时机 - 不要在
requestAnimationFrame回调里做大量计算或 DOM 查询，否则可能超 16ms，直接丢帧；复杂逻辑建议用Web Worker或拆分到多帧 - 若动画基于时间（而非帧数），务必用传入的
timestamp计算差值，而不是靠++frameCount—— 否则在低帧率设备上会变慢
真正难的不是调用这个函数，而是设计好状态更新节奏、避免隐式重排、处理好跨设备帧率差异。这些细节没压住，再“正确”的调用也救不了动画体验。
