requestanimationframe 本身生效，卡顿主因是单帧逻辑超16ms预算；常见问题包括全屏clearrect、未缓存绘图、dom查询、重排重绘、频繁gc及离屏canvas误用。
requestAnimationFrame 调用后动画还是卡，是不是没生效？
requestAnimationFrame 本身不保证帧率，它只是把回调“排队”进浏览器的渲染队列。掉帧真正的原因，往往是你的绘图逻辑在单帧里干了太多事，超出了 16ms（60fps）的预算。
- 动画循环里做了 DOM 查询（比如反复调用
document.getElementById）、重排（offsetTop、getComputedStyle）或重绘（频繁改style） - Canvas 绘图用了未缓存的路径、重复创建
Path2D或CanvasGradient - 每帧都调用
clearRect清全屏，但实际只需局部擦除 - 回调函数里触发了垃圾回收（比如新建大量临时对象、字符串拼接）
示例：错误写法
function animate() {
ctx.clearRect(0, 0, canvas.width, canvas.height); // 全屏清空，开销大
ctx.beginPath();
ctx.arc(x, y, r, 0, Math.PI * 2); // 每帧重绘路径
ctx.fill();
requestAnimationFrame(animate);
}Canvas 绘图性能瓶颈常出在 clearRect 和 drawImage 上
clearRect 看似轻量，但在高 DPI 屏幕或大尺寸 Canvas 上，它要清的是物理像素，可能达数百万点；drawImage 如果传入未预加载/未缓存的图像，会触发同步解码，直接卡死一帧。
- 优先用“脏矩形”局部清除：
ctx.clearRect(dirtyX, dirtyY, dirtyW, dirtyH)，只清变化区域 - 图片资源必须提前用
img.onload加载完成，再传给drawImage；避免在动画循环里 new Image() - 复杂静态元素（如 UI 图标、背景）先绘制到离屏
canvas，再用drawImage整块贴上（即“图层缓存”） - 避免在每帧里调用
ctx.save()/ctx.restore()，它们开销比想象中高；改用显式设置ctx.globalAlpha、ctx.setTransform
为什么用 requestAnimationFrame 也压不住 30fps？
不是 requestAnimationFrame 不够快，而是浏览器主动降频了——常见于页面非激活状态（标签页切走）、Canvas 元素不可见、或设备进入省电模式。
立即学习“前端免费学习笔记（深入）”；
- 检查
document.hidden，切后台时暂停动画，回来再恢复，别硬撑 - 不要用
setTimeout+ 固定毫秒数（如 16）模拟帧率，它和屏幕刷新不同步，反而加剧撕裂和掉帧 - 移动端尤其注意：部分 Android WebView 对
requestAnimationFrame支持不稳定，可加降级兜底（如监听visibilitychange后 fallback 到setTimeout） - 真实帧耗时得靠
performance.now()测，别信控制台的 FPS 显示；例如：let lastTime = 0; function animate(timestamp) { const delta = timestamp - lastTime; lastTime = timestamp; console.log('frame time:', delta); // >16.7 表示已掉帧 // ...绘图逻辑 requestAnimationFrame(animate); }
离屏 Canvas 缓存不是万能的，用错反而更慢
把内容画到离屏 canvas 再贴回主 Canvas，确实能减少重复计算，但前提是：该内容更新频率远低于动画帧率（比如每秒变一次的 UI 文字），且离屏 Canvas 尺寸合理。
- 离屏 Canvas 过大（比如跟主 Canvas 一样大），每次
drawImage仍是全量像素搬运，没节省 - 频繁修改离屏 Canvas 内容（比如每帧都重绘文字），等于把瓶颈从主 Canvas 搬到了离屏 Canvas
- 离屏 Canvas 没设
width/height属性，而是仅靠 CSS 缩放，会导致绘制时自动缩放+模糊+性能下降
关键判断点：只对「静态或低频变化」的图层做离屏缓存；高频动画元素（如粒子、角色位移）仍应在主 Canvas 直接绘制，配合脏矩形和 transform 优化。
Canvas 动画掉帧，很少是 requestAnimationFrame 的锅，绝大多数时候，问题藏在你每帧做的具体事情里——尤其是那些看起来“应该很快”的操作，比如清屏、取样式、new 一个对象。
