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