游戏循环应使用requestAnimationFrame而非setInterval，以对齐屏幕刷新率、省电且稳定；需分离更新与渲染，用固定时间步长累积deltaTime并保留余量，避免逻辑帧率波动；update只改状态，render只负责绘制；须清理raf防止内存泄漏。
游戏循环的核心是 requestAnimationFrame，不是 setInterval
用 setInterval 驱动游戏帧更新会导致时间漂移、卡顿、掉帧不可控。浏览器原生的 requestAnimationFrame 会自动对齐屏幕刷新率（通常是 60Hz），并能在标签页非激活时暂停调用，省电又稳定。
常见错误是把游戏逻辑和渲染混在同一个 requestAnimationFrame 回调里，导致逻辑帧率被渲染拖累。理想做法是分离「更新」和「渲染」：
- 用固定时间步长（如 16.67ms）累积时间，只在达到阈值时执行一次
update() - 每次
requestAnimationFrame都执行render()，不管逻辑是否更新 - 用
performance.now()获取高精度时间戳，避免Date.now()的毫秒截断误差
如何实现带时间补偿的固定逻辑帧率
真实帧率波动不可避免，直接按每帧 16.67ms 更新会导致加速或减速。必须做时间差累积 + 剩余时间保留。关键点：
- 目标帧时间为
1000 / 60≈16.666...ms，记为TARGET_FRAME_TIME - 每次回调用当前时间减去上一帧时间，得到
deltaTime - 把
deltaTime累加到accumulator，再循环执行update()直到accumulator - 最后把剩余的
accumulator留给下一帧，避免时间丢失
const TARGET_FRAME_TIME = 1000 / 60; let lastTime = performance.now(); let accumulator = 0;function gameLoop(currentTime) { const deltaTime = currentTime - lastTime; lastTime = currentTime; accumulator += deltaTime;
while (accumulator >= TARGET_FRAME_TIME) { update(TARGET_FRAME_TIME); // 固定步长更新 accumulator -= TARGET_FRAME_TIME; }
render(); // 每帧都渲染，利用最新状态 requestAnimationFrame(gameLoop); }
requestAnimationFrame(gameLoop);
立即学习“Java免费学习笔记（深入）”；
为什么不能在 update() 里直接修改 DOM 或 Canvas 坐标
DOM 操作和 Canvas 绘制本身不耗时，但若在 update() 中触发重排（offsetTop、getComputedStyle）或频繁创建绘图路径，会打断渲染流水线，造成隐式同步开销。更严重的是：如果 update() 耗时超过 16ms，就会挤占 render() 时间，导致画面撕裂或跳帧。
- 所有状态变更（如
player.x += speed * dt）应在update()中完成 - 所有绘制指令（
ctx.fillRect()、element.style.left）必须只出现在render()中 - 避免在
update()中调用console.log、alert或任何可能触发微任务/宏任务的操作
cancelAnimationFrame 必须在页面卸载或暂停时显式调用
即使用户切走标签页，requestAnimationFrame 在部分旧版浏览器中仍可能继续触发（尤其配合 Web Workers 时）。没清理会导致内存泄漏、后台 CPU 占用升高，甚至影响其他页面性能。
- 监听
visibilitychange事件，在document.hidden === true时调用cancelAnimationFrame - 在组件销毁（如 React
useEffect清理函数、VuebeforeUnmount）中保存并清除requestId - 不要依赖浏览器自动暂停——Safari 15.4 之前、某些 WebView 环境下行为不一致
最易被忽略的是：游戏暂停（pause）状态 ≠ 循环停止。暂停时应保留 lastTime 和 accumulator，等恢复后继续累积，否则 resume 会瞬间补一大段逻辑更新，角色瞬移或判定错乱。
