canvas动画掉帧主因是“画得不准”，需用requestanimationframe对齐浏览器渲染节奏，结合时间戳动态节流、visibilitystate控制启停，并严控单帧16ms工作量。
Canvas动画掉帧，核心问题不在“画得慢”，而在“画得不准”——定时器选错、时间逻辑混乱、资源调度失当，都会让60fps变成幻觉。真正平滑的动画，靠的是与浏览器渲染节奏同频，而不是强行塞帧。
用requestAnimationFrame替代setInterval/setTimeout
setInterval(16)看似能锁60fps，实则隐患重重：它不感知屏幕刷新节奏，JS繁忙时严重延迟，后台标签页仍运行耗电，还容易引发画面撕裂。requestAnimationFrame由浏览器统一调度，自动对齐显示器刷新率，标签页不可见时暂停调用，是Canvas动画的唯一推荐入口。
- ✅ 正确写法：递归调用rAF，每次回调带高精度时间戳
- ❌ 避免写法：setInterval(() => { render(); }, 16) 或 setTimeout循环
- ⚠️ 兜底场景（如兼容IE9）：可用performance.now() + rAF模拟，但不建议作为主力方案
基于时间戳的动态节流，精准控帧
rAF本身不保证每16.67ms执行一次，实际间隔会浮动。靠固定计数器（如“每2帧画1次”）虽简单，但无法应对设备性能波动或页面切后台后的恢复。更健壮的做法是用时间差（deltaTime）做动态判断：
- 记录上一帧的时间戳（用performance.now()，非Date.now()）
- 计算本次回调距上次的真实毫秒数
- 仅当该时间 ≥ 目标帧间隔（如1000/60 ≈ 16.67ms）时才执行render()
- 更新时间戳，继续下一轮
这样即使某帧卡顿了30ms，下一帧也不会堆积补画，而是自然跳过，保持节奏稳定。
结合visibilityState主动暂停与恢复
用户切走标签页时，浏览器虽会降低rAF频率，但部分逻辑（如数据轮询、音频同步）可能仍在后台运行。主动监听document.visibilityState可彻底规避资源浪费：
- 页面隐藏时：保存当前状态，停止requestAnimationFrame调用
- 页面重新可见时：重置时间戳或计数器，再启动rAF循环
- 避免切回瞬间因积压大量未执行帧导致卡顿或跳跃
减少单帧工作量，守住16ms底线
浏览器每帧留给JS和绘制的时间约16ms。掉帧往往不是rAF没调用，而是单帧内做了太多事：
- 避免在animate回调里做复杂遍历、物理计算或大量DOM操作
- 高频逻辑（如粒子运动）可抽离为独立worker或分帧处理
- 用deltaTime驱动状态更新，而非依赖rAF频率——例如“每秒移动100px”，应写成ball.x += (deltaTime / 1000) * 100，而非ball.x += 1.67
- 清空画布用clearRect，比fillRect全屏填充更快；若背景静态，甚至可跳过clearRect，只重绘变化区域
