Unity 前端联网知识概要：从 HTTP 到 WebSocket 到帧同步客户端

这篇是 Unity 侧联网的知识地图。我写它的时候正把前端从 Unity 切到 Cocos（小游戏包体/工作流原因），但 Unity 这套联网思路是通用的——而且团结引擎（Tuanjie）导出微信小游戏时基本都适用。

一、传输层怎么选

• HTTP：登录、拉配置、商城这类一次性请求，用 UnityWebRequest 或 HttpClient（注意 AOT/IL2CPP 下的裁剪问题）。
• WebSocket：微信端实时对战的常用选择（平台不提供裸 TCP/UDP）。Unity 引擎本身没有内置 WebSocket，装插件即可——常用的有 BestWebSocket（付费、全平台支持、维护活跃）和 NativeWebSocket（免费开源、对 WebGL/小游戏导出友好）。原生平台也可以不走 WebSocket，直接用裸 TCP 甚至 UDP+KCP。
• 裸 TCP/UDP：微信小游戏环境不可用；PC/手游原生可以，但除非做 UDP+KCP 级别的延迟优化，否则不值得。

二、序列化与协议设计

• 实时对战走二进制协议：自定义包头 + protobuf 消息体。JSON 只在调试期/低频管理接口用。
• protobuf 在 Unity 里用 protobuf-net（C# 特性标注即可）或服务端共享的 .proto 生成——两端同源是防协议漂移的关键。
• 消息类型注册表是易踩点：收包时查不到注册类型要能看见日志，否则就是"静默丢包"。

三、连接生命周期

• 心跳探活：收包静默超时判假死（移动端 socket 假死不会触发断开事件），主动关连接再重连。
• 指数退避重连（1/2/4/8s 封顶 + 次数上限），配合应用前后台切换（OnApplicationPause）做校准。
• 会话凭证：断线重连需要 resumeToken 之类的凭证回房间；新会话上没有任何绑定，重连后要重新走"登录→进逻辑服→Resume"三步。

四、帧同步客户端要做的事

• 固定步进（如 20Hz）推进确定性模拟，逻辑与渲染帧率解耦；
• 指令上行不打帧号，等服务端定帧广播回来再应用（输入延迟窗约 200ms 是体感与一致性的平衡点）；
• 落后就倍速追帧（快放而非跳剪），追平回正常速。

五、团结引擎/小游戏导出的特殊注意

• WebSocket 在小游戏环境走微信 API，Unity 侧需要 jslib 桥接（weapp-adapter 的 WebSocket 全局）。
• 编辑器里一切正常不代表真机正常——假死、线程模型、编码（GBK/UTF-8 混用会在构建期炸）都是真机才现形的坑。
• 编辑器批处理构建（-batchmode）可以接 CI，但编辑器占用冲突是家常便饭，日志位置要先想好。