requestAnimationFrame 更适合动画因其自动对齐浏览器刷新节奏、具备页面不可见时自动暂停的节流能力，且提供高精度时间戳用于精准帧控。
requestAnimationFrame 为什么比 setTimeout 更适合做动画
因为 requestAnimationFrame 会自动对齐浏览器的刷新节奏（通常是每秒 60 帧），而 setTimeout 是基于系统时钟计时，容易出现掉帧、卡顿或“撕裂”。它还具备自动节流能力——页面不可见时（比如切到其他 tab），requestAnimationFrame 会被浏览器暂停，省电又省资源。
常见错误现象：setTimeout(..., 16) 看似想模拟 60fps，但实际执行时机不可控，连续多次调用后误差累积，动画越来越拖慢；更糟的是，用户滚动页面或触发重排时，setTimeout 仍强行执行，造成大量无意义计算。
- 不要手动算 16ms：浏览器刷新率不总是 60Hz（比如高刷屏是 120Hz，对应约 8.3ms）
- 不要嵌套多个
setTimeout模拟循环：这会绕过浏览器的帧调度机制 -
requestAnimationFrame回调接收一个时间戳参数（DOMHighResTimeStamp），应优先用它计算 delta，而不是依赖Date.now()
如何正确写一个 requestAnimationFrame 动画循环
核心是“递归调用 + 时间差控制”，不是简单地在回调里再调一次 requestAnimationFrame 就完事。你需要记录上一帧时间，根据当前帧时间差决定是否更新状态，否则动画速度会随帧率浮动（比如在低性能设备上变慢）。
let lastTime = 0;
function animate(currentTime) {
if (!lastTime) lastTime = currentTime;
const deltaTime = currentTime - lastTime;
lastTime = currentTime;
// 例如：让元素每秒移动 100px
const speed = 100; // px/s
element.style.transform = translateX(${(speed * deltaTime / 1000).toFixed(2)}px);
requestAnimationFrame(animate);
}
requestAnimationFrame(animate);
注意点：
- 必须用传入的
currentTime（不是Date.now()），它是高精度单调递增时间戳 - 避免在回调中做重排（如读取
offsetTop）或重绘（如频繁改 style），否则触发同步布局，严重拖慢帧率 - 如果动画需暂停/恢复，保存
requestId并用cancelAnimationFrame控制
requestAnimationFrame 和 CSS 动画该选哪个
优先用 CSS 动画（transition 或 @keyframes），因为它们由浏览器渲染线程直接驱动，不经过 JS 主线程，性能更高、更省电。JS 的 requestAnimationFrame 只应在需要动态计算（比如跟随鼠标、物理模拟、滚动联动）时使用。
典型误用场景：
- 只做简单位移/缩放/透明度变化，却用 JS +
requestAnimationFrame手动更新style→ 应改用transition - 在
requestAnimationFrame中反复读写同一元素的offsetLeft和style.left→ 强制同步布局，直接干掉 60fps - 用
requestAnimationFrame驱动 SVGtransform却没开启 will-change 或 contain → 浏览器无法启用 GPU 加速
兼容性与降级处理要不要做
现代浏览器（Chrome 24+、Firefox 23+、Safari 6.1+、Edge 10+）都支持 requestAnimationFrame，IE10+ 有带前缀的 msRequestAnimationFrame，但 IE 已退出主流支持。除非明确要兼容 IE
9 及更早版本，否则无需降级到 setTimeout。
如果真要兼容，可用这个轻量 fallback：
const raf = window.requestAnimationFrame ||
window.webkitRequestAnimationFrame ||
window.mozRequestAnimationFrame ||
window.msRequestAnimationFrame ||
function(callback) {
return setTimeout(callback, 1000 / 60);
};但要注意：这个 fallback 在低帧率设备或后台 tab 中不会自动降频，可能持续消耗 CPU。真正关键的动画逻辑（比如游戏、可视化）建议直接放弃 IE9–。
最常被忽略的一点：很多人以为只要用了 requestAnimationFrame 就一定丝滑，其实它只是“调度器”，动画是否流畅，最终取决于每一帧内做的操作是否轻量——比如 layout thrashing、强制同步重排、未优化的 canvas 绘制，都会让 requestAnimationFrame 失效。
