网络与服务端：让客户端顺滑，让结果可信
这部分最能复用你的后端经验。新的挑战是：客户端同时有交互、动画和场景生命周期，网络请求回来时，玩家可能已经离开这局游戏。
哪些事情放在哪里
客户端负责即时手感、预测与展示；服务端负责身份、关键资产、奖励规则和可信持久化。客户端可以报告一次游玩结果，但不应凭一个 score=999999 就获得排行榜奖励。
| 场景 | 通信方式候选 | 需要明确 |
|---|---|---|
| 登录、配置、进度、结算 | 请求/响应 | 超时、幂等、版本冲突 |
| 状态通知、房间聊天 | 长连接或其他推送方案 | 心跳、重连、顺序与去重 |
| 强实时对战 | 专门的同步架构 | 服务器裁决、延迟、预测和校正 |
Creator 与微信环境提供网络能力，但域名、安全协议和平台配置仍应按目标环境验证。不要在示例里假定浏览器的所有 Web API 都在小游戏同样可用。
一次结算的可靠路径
请求超时不代表服务端没有执行。重试结算应复用同一幂等标识，不能重新生成一个“新奖励请求”。有价值的奖励还需要进一步的校验方案，不能只依赖客户端时间戳。
UI 中要有网络状态
idle、loading、success、error 应能在画面中辨认。加载时禁用会重复提交的按钮；失败后恢复可操作；退出后不继续修改旧 UI；弱网下有合理的等待与重试说明。
关键请求记录请求 ID、roundId、错误类别与耗时即可，不记录登录 code、会话凭据或 AppSecret。
向 AI 提需求
为进度同步设计客户端与服务端协议。
客户端带本地版本；服务端检查冲突，返回确认后的进度与版本。
区分离线、超时、登录失效、业务拒绝；不要所有错误都无限重试。
旧局响应不得覆盖新局 UI，结算重试复用同一幂等键。
先给协议与状态图，再写目标平台的请求代码。
验收：断网、超时后实际已成功、重复提交、会话失效、乱序返回、切场景后返回，分别有确定结果。
依据：Creator HTTP 请求、WebSocket 简介、发布到微信小游戏。协议与幂等策略是本文建议，需结合服务端业务设计。