rAF是HTML5游戏主循环最自然高效的方式，需围绕它构建含update/render分离、deltaTime驱动、固定逻辑步长+插值、节流与暂停机制的轻量结构。
requestAnimationFrame（rAF）是 HTML5 中实现游戏主循环最自然、最高效的方式，但它本身只是一个“帧调度器”，不提供时间控制、状态管理或逻辑分离能力。要管理复杂游戏主循环，关键不是只调用 rAF，而是围绕它构建一套轻量但清晰的结构：把更新（update）、渲染（render）、时间测量、帧节流和生命周期控制都组织起来。
用 delta time 驱动逻辑，不依赖帧率
浏览器的 rAF 调用频率不固定（可能 30fps、60fps 甚至更高），直接在每帧执行一次移动/物理计算会导致速度随帧率漂移。必须基于真实经过的时间做增量更新：
- 记录上一帧的时间戳（通过 rAF 回调参数或 performance.now()）
- 计算本次与上次之间的时间差（deltaTime），单位建议统一为毫秒或秒
- 所有运动、计时器、动画进度都乘以 deltaTime（例如：x += speed * deltaTime / 1000）
这样即使某帧卡顿 100ms，角色也只多走对应距离，不会“瞬移”或漏掉碰撞检测。
分离 update 和 render，支持可变帧率下的稳定模拟
对物理精度要求高的游戏（如平台跳跃、弹道预测），不能让 update 频率跟随渲染帧率波动。常见做法是固定逻辑更新步长（如 16.67ms ≈ 60Hz），而渲染尽可能跟显示器刷新率走：
- 维护一个累积时间变量（accumulator）
- 每帧用 deltaTime 累加 accumulator
- 当 accumulator ≥ 固定步长时，执行一次 update，并减去该步长；可连续执行多次（防止卡顿导致逻辑滞后）
- render 始终在 rAF 回调中执行，使用插值位置（根据剩余 accumulator 比例）提升视觉流畅度
这本质是 “Fixed Timestep + Interpolation”，是《Fix Your Timestep!》文章推荐的标准实践。
添加节流与暂停机制，兼顾性能与体验
rAF 在标签页非激活或后台时会自动降频甚至暂停，但你仍需主动处理以下情况：
- 页面失焦（visibilitychange 或 document.hidden）时暂停 update，避免后台耗电/运算；恢复时重置时间戳，防止大 deltaTime 冲击
- 帧率过低（如持续
- 用布尔标志（如 isRunning）控制主循环开关，便于调试、关卡切换或暂停菜单
注意：不要用 setTimeout/setInterval 模拟 rAF，也不要用 CSS 动画替代核心游戏逻辑——它们不可控、不同步、难调试。
模块化主循环入口，避免逻辑耦合
把主循环写成一个可组合的函数，而非巨型 switch 块：
- 主函数只负责时间测量、调用 update/render、处理节流
- update 函数内按系统拆分：input.update()、physics.update()、ai.update()、entity.update()…
- render 同理：camera.render()、sprite.render()、ui.render()，并支持脏标记（dirty flag）跳过未变化对象
- 用简单事件或回调支持“进入后台”“窗口大小变化”等外部信号
这样代码易测试、可复用、便于多人协作——比如 physics.update 可独立单元测试，无需 DOM 或 rAF 环境。
不复杂但容易忽略。核心就三点：用好 deltaTime、固定 update 步长、保持 update/render 解耦。rAF 是画布，你才是执笔的人。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
