用requestAnimationFrame构建Canvas动画需遵循四大原则：一、用isRunning状态机控制启停循环；二、基于performance.now()计算delta time实现帧率无关运动；三、局部清屏、离屏渲染、复用Path2D优化绘制；四、分离逻辑与渲染，耗时操作移至Web Worker或requestIdleCallback。
用 requestAnimationFrame（简称 rAF）构建 Canvas 动画，核心在于建立一个**稳定、可控、与屏幕刷新率同步**的循环逻辑，而不是简单套用 setInterval 或递归 setTimeout。关键不是“怎么调用 rAF”，而是“在每一帧里该做什么、怎么做才不掉帧、不卡顿”。
一、基础循环结构：避免隐式递归陷阱
rAF 本身是单次调用，必须手动“续订”才能形成动画循环。常见错误是直接在回调里无条件再调一次 rAF：
function animate() {
draw(); // 绘制
requestAnimationFrame(animate); // ❌ 没有控制条件，停不下来
}
animate();
正确做法是把循环逻辑封装成可启停的状态机：
- 用布尔变量（如
isRunning）控制是否继续下一帧 - 每次 rAF 回调开头检查状态，决定是否继续调用
- 提供
start()和stop()方法，方便生命周期管理
二、时间驱动：用 delta time 实现帧率无关运动
不要假设每帧都是 16.67ms（60fps）。设备负载、后台标签页、高刷新率屏幕都会导致实际间隔波动。应基于真实时间差计算位移：
- 记录上一帧的时间戳（
lastTime），当前帧用performance.now()获取新时间戳 - 计算差值
delta = now - lastTime（单位毫秒） - 运动逻辑写成
position += speed * (delta / 1000)，即按秒为单位的速度缩放
这样即使某帧卡顿 50ms，对象也不会“瞬移”，而是平滑补足该时段应走的距离。
三、绘制优化：只清必要区域 + 合理复用上下文
Canvas 性能瓶颈常出在绘制阶段：
- 避免全屏
clearRect(0, 0, width, height)，若背景静止或仅局部变化，用save()/restore()配合局部擦除或重绘 - 对静态元素（如 UI 背景、地图底图）预渲染到离屏 canvas，主画布只 composite（
drawImage(offlineCanvas, ...)） - 减少路径重建：缓存
Path2D对象，重复使用；避免在动画循环中频繁调用beginPath()+ 大量lineTo()
四、逻辑与渲染分离：避免阻塞主线程
动画循环里别混入耗时操作：
- 物理计算、碰撞检测、AI 决策等逻辑应尽量轻量；复杂运算考虑 Web Worker 分离
- 资源加载（图片、字体）、DOM 操作、网络请求绝不能放在 rAF 回调内
- 用
requestIdleCallback处理低优先级任务（如日志上报、非关键状态同步）
保持 rAF 回调执行时间
不复杂但容易忽略：rAF 的本质是浏览器调度承诺——它不保证精确帧率，但保证在最合适时机唤醒你。真正决定动画质量的，是你在那一帧里做的每件事是否克制、是否可预测、是否尊重渲染管线。
