如果游戏客户端能直接告诉后端玩家得了多少分，那这款游戏已经被破解了。在开发 Space Cargo Runner 时，团队遇到的最大工程挑战并不是在浏览器里跑出 60 FPS，而是搭建一套防篡改、服务器权威的后端架构，在不掉一帧的前提下同步实时多人状态。

这是一款赛博朋克主题的实时街机跑酷游戏，试图把传统浏览器游戏和 Web3 代币经济连接起来。当分数与代币经济挂钩时，信任客户端就成了致命错误。下面从系统设计、反作弊机制和状态桥接架构三个层面拆解这套方案。

打开网易新闻 查看精彩图片

60 FPS 游戏循环与 React 解耦

Phaser 3 运行在它自己的 requestAnimationFrame 画布生命周期里，完全独立于 React DOM 树之外。问题在于，如果试图通过每一帧触发标准的 React useState 钩子来同步游戏状态——坐标、当前速度、燃料水平、护盾完整度——每秒 60 到 120 次的频率会让 React 的协调引擎产生灾难性的 CPU 瓶颈和掉帧。

解决方案是把 Zustand 当作一个解耦的状态中介，而不是把 React 状态直接绑定到游戏 tick 上。在共享包里定义一个状态桥接模块，包含燃料、生命值、货物数量和倍率等字段，并提供一个批量更新方法。Phaser 的 update() 循环里直接调用这个桥接方法，把玩家当前的燃料、生命值和本局货物数推过去。

React 的 HUD 覆盖层只选择性订阅自己需要渲染的字段。这样一来，画布能以顺滑的 60 FPS 运行，DOM 层不会产生任何卡顿。

服务器权威的反作弊与分数验证

在单机网页游戏里，恶意玩家可以打开 Chrome DevTools，检查内存、修改本地变量，或者直接伪造一个 HTTP POST 请求，比如 POST /api/score 带上 score: 9999999。当分数与代币经济挂钩时，信任客户端是致命的。

这套架构的验证流程是这样的：

  1. Phaser 客户端把带时间戳的输入和种子发送给 Node.js Express API
  2. 客户端本地只负责视觉表现，跑游戏循环
  3. 服务端用回放引擎做确定性校验，判断分数是否有效

具体到验证引擎，客户端会流式传输一个压缩数组，里面是带时间戳的玩家操作——方向切换、加速激活、道具触发——同时附上初始的 PRNG 种子。一局跑完后，Node.js 后端进行确定性的服务端回放。

这套机制的核心逻辑是：客户端只负责画面，真正的判定权在服务端。玩家在本地看到的一切都只是视觉效果，分数是否成立由服务端回放决定。

状态桥接架构的关键取舍

把游戏循环和 UI 渲染拆开，是这套方案里最基础也最关键的一步。Phaser 管画布，Zustand 管状态中转，React 只管订阅和展示。三者各司其职，谁都不越界。

反作弊部分则把信任从客户端彻底拿走。输入向量被记录下来，种子被记录下来，服务端重放一遍，结果对不上就不算数。对于一款和代币经济挂钩的游戏来说，这不是可选项，而是前提。

整套设计要解决的是同一个矛盾：浏览器端要流畅，后端要可信，两者还不能互相拖累。Space Cargo Runner 给出的答案是——让画布跑自己的循环，让状态走独立的中转层，让分数由服务端说了算。