为什么我的游戏每次重开都会越跑越快？

这个故障是玩家报出来的，日志也直说了：正是因为玩家报告了异常表现，问题才被发现。这一点很重要，因为这类故障不会用崩溃或报错来宣告自己。游戏照样能跑，只是跑得不对，而且表现得像变快了，而不是坏掉了。只重开一次的玩家可能什么都察觉不到；重开几次的玩家会得到一款亢奋过头的游戏，本能反应是怪帧率上限、画质设置或机器。可在这个案例里，这些都不是问题，问题是数量：太多循环在同时做同一件工作。这种不匹配也正是症状容易被误读的原因。变快感觉像是性能提升，所以玩家可能先怀疑是设置被改了或上限被调高了，而实际上游戏只是把同一件工作做了好几遍。数循环，而不是欣赏速度，才能把症状重新变回诊断。

要看清这是怎么发生的，得跟着日志描述的循环走。一个叫 animate() 的函数负责更新 3D 场景、移动物体、检测碰撞。游戏用 setInterval(animate, 1000 /

60) 每秒跑它 60 次，一个叫 startGame() 的函数负责创建这个定时器，一个叫 endGame() 的函数负责清除它。到这里都很规整，麻烦出在重开路径上：流程是一局结束走 endGame()，到游戏结束画面，再走 restartGame()，然后 startGame() 又被调用，于是产生一个新的动画循环。可日志说，有时候旧的定时器没有及时清除，甚至根本没有清除。于是每次重开都可能留下一个幸存者：两个 animate 循环同时跑，然后是三个、四个，每个都往浏览器上叠加更多的绘制调用，游戏就快得离谱。日志给出的范围很直白：重开几次之后，游戏可能同时跑着 3 个、5 个乃至 10 个循环。同一段代码里还藏着第二个陷阱：animate() 里有一行守卫 if (!gameStarted) return;，它只停住了逻辑，没有停住定时器本身。嘴上说停的标志，不等于真正停下的循环，而这个故障就是这种差别在真实游戏里的样子。

日志给出了三项改进，其中第一项是承重的那一项：启动新循环之前，永远先清除旧的动画循环。一个新函数 stopGameLoop() 负责清除定时器并把句柄置空，而且每次启动之前都会先调用它。在日志展示的最终流程里，startGame() 先调用 stopGameLoop()，再调用 initializeScene()，然后调用 startGameLoop()，而 startGameLoop() 自己在创建定时器之前又会再调用一次 stopGameLoop()。顺序就是关键：启动循环不再被允许假定上一个循环已经没了，它必须先停掉现有的东西来证明这一点。用日志自己的话说，这才能保证任何时候只有一个活动循环。如果这个案例只让你记住一句话，那就记住这个顺序：每次都先停再开，毫无例外。

第二项改进清理的是场景本身。日志指出，Three.js 会把对象存在显存里，旧场景留在内存里会拖慢速度。所以在开始新一局之前，一个叫 cleanupScene() 的函数用 scene.traverse 遍历场景，释放几何体、材质与材质贴图，然后调用 renderer.dispose()。日志对这一步的总结是：没有任何东西会被带到下一局。第三项改进拆掉了那个误导人的守卫：if (!gameStarted) return; 这一行从 animate() 里拿掉，循环改用真正清除定时器的方式来停，而不是靠一个标志假装循环已经关了。报告的结果特意保持克制，本文也保持克制：重开之后帧率不再飙升，而且无论玩家回主菜单或开新局多少次，游戏表现都一致。日志把结果形容为顺滑、内存安全、可预测、帧率稳定，但它没有给出任何帧率数字，所以本文也不给。不要把来源从没说过的数字读进它的说法里。

下面的步骤不是 Velocity Puck 开发者在已述三项改进之外做过的事，而是把这些改进推广到你自己项目的清单，全部只停留在你自己的项目里。能复用的思路是循环的所有权：谁启动了循环，谁就要负责停掉它，而重开路径正是所有权最容易断掉的地方，因为顺风顺水的首次启动被测得远比第五次运行的路径多。一款首次启动表现正常、第五次重开却出问题的游戏，是在告诉你它的启动与停止逻辑不一致。修复办法不是更快的循环或更严的帧率上限，而是一条单一且强制执行的规则：旧循环没有被证明已经消失之前，不许启动新循环；旧场景也不许活到新一局里。像真实玩家那样去测重开：反复测、不耐烦地测、从每一个能回到比赛的界面测。这正是顺风顺水的首次启动永远给不了你的测试，也是本可以在玩家上报之前就抓住这个故障的测试。