Canvas动画需同步执行清屏、重绘、状态更新三步，漏任一环会导致残影或卡顿；clearRect必须置于帧首以清除位图残留；应避免重置上下文或局部清屏；需用deltaTime校准逻辑、Float32Array优化数据结构，并管控对象生命周期。

Canvas 动画不是靠 requestAnimationFrame 就能“动起来”的——关键在清屏、重绘、状态更新三步是否同步，漏掉任意一环就会出现残影、卡顿或逻辑错位。

为什么 clearRect 必须放在每一帧开头？

Canvas 是位图绘制，没有 DOM 那样的自动图层管理。上一帧画过的内容会一直留在缓冲区里，除非手动擦除。

• 只调用 drawImage 或 fillRect 而不 clearRect → 画面越叠越多，形成拖尾或重影
• 用 canvas.width = canvas.width “偷懒清屏” → 会重置所有上下文状态（如 lineWidth、fillStyle），后续绘图可能失效
• 清屏区域小于 canvas 实际尺寸（比如只清 0,0,300,200）→ 边缘残留旧内容，尤其在缩放或响应式布局下极易暴露

function animate() {
  // ✅ 正确：完整清屏，保留当前上下文设置
  ctx.clearRect(0, 0, canvas.width, canvas.height);
// 更新状态（如小球位置）
x += dx;
y += dy;
// 重绘
ctx.beginPath();
ctx.arc(x, y, 10, 0, Math.PI * 2);
ctx.fill();
requestAnimationFrame(animate);
}

requestAnimationFrame 和 setTimeout 切换时的掉帧陷阱

requestAnimationFrame 的执行时机由浏览器决定，通常约每 16.7ms 一次（60fps），但前提是 JS 主线程不被长时间阻塞。一旦你在这帧里做了大量计算或 DOM 操作，这一帧就直接丢弃。

• 在 requestAnimationFrame 回调中执行耗时循环（如遍历 10000 个粒子）→ 当前帧卡死，下一帧延迟，动画“一卡一卡”
• 用 setTimeout(..., 16) 模拟帧率 → 时间不可靠，容易漂移，且无法与屏幕刷新同步，iOS Safari 下尤为明显
• 动画逻辑未做时间差校准（即忽略 deltaTime）→ 设备性能差异大时，快机器跑得飞快，慢机器慢如幻灯片

let lastTime = 0;
function animate(timestamp) {
  const deltaTime = timestamp - lastTime;
  lastTime = timestamp;
// 按实际间隔更新逻辑（例如：目标移动速度 100px/s）
x += (100 / 1000) * deltaTime; // 单位统一为 ms
ctx.clearRect(0, 0, canvas.width, canvas.height);
ctx.fillRect(x, y, 20, 20);
requestAnimationFrame(animate);
}

Canvas 动画性能瓶颈常不在绘图，而在数据结构和状态管理

很多“动画变慢”的问题，根源是每帧都在重复创建对象、拼接字符串、或做无谓的坐标转换。

• 每帧都 new 一个 Path2D 或调用 ctx.isPointInPath → GC 压力陡增，尤其在低端 Android 设备上明显卡顿
• 用 toDataURL() 截图做缓动预览 → 触发全量像素读取，强制同步，单次调用就可导致 50ms+ 阻塞
• 粒子系统中用数组存 5000 个 {x, y, vx, vy} 对象 → V8 引擎对稀疏对象优化差，比用 Float32Array 慢 3–5 倍

// ✅ 更快的粒子存储方式
const particles = new Float32Array(5000 * 4); // x, y, vx, vy
// particles[i * 4]     → x
// particles[i * 4 + 1] → y
// particles[i * 4 + 2] → vx
// particles[i * 4 + 3] → vy

Canvas 动画真正的复杂点，往往藏在「状态生命周期」里：什么时候初始化、什么时候销毁、哪些变量该缓存、哪些必须每帧重算——这些不会报错，但会悄悄吃掉帧率，直到你在真机上滑动两下才意识到不对劲。