牌桌 Protobuf 传输

上一轮紧凑 JSON 已经省掉默认值和重复字段，剩下的大头是每次动作都要发给同桌九人的公共事件，它们仍在反复携带字段名和 JSON 结构。2026 年 9 月，我们让 H5 协商 protobuf-v1，只把 actor_deadline、action_applied、pot_updated、street_revealed 四类高频公共事件改成二进制；快照、私牌和其他控制消息仍走原来的 JSON 路径与隐私投影，REST 不变，也没有开通用压缩。

在生产版本上用 100 桌、900 个连接做对照（同一服务端二进制，只换协商的协议）：WS 下行载荷从约 1.73 MB/s 降到 0.93 MB/s，每次完成动作从 4,181 B 降到 2,254 B，约少 46%；同日 100 桌复测为 45.8%–46.3%，五轮复测共 240,000 个 REST 请求全部成功。但两种协议的动作吞吐都约为每秒 414 次，客户端端到端延迟也没有测出改善（压测器与服务共用一台双核主机），所以这是“少发 46% 字节”，不是“吞吐或承载人数提高 46%”。这些数字只计应用层载荷，不含 WebSocket 帧头、TCP 和 TLS。

二进制能解码不等于状态正确：座位 0 是真实座位，min_raise_to 为空和为 0 含义不同，因此 schema 用 optional 区分缺失值，H5 还原为原有消息结构，64 位筹码超出 JavaScript 安全整数范围就拒绝该帧，不悄悄四舍五入。代价是多一份 schema、生成代码和解码适配层，抓包与压测工具也要能读二进制，否则会报出虚假的低流量。

经验是先看占比再估收益：四类事件约占 JSON 轮次总载荷的 52.2%，自身缩小约 85.6%，52.2% × 85.6% ≈ 44.7%，与实测约 46% 接近；只展示最小一条消息的压缩率会高估业务收益。以上是历史实验，当前传输已改为差分信封加字典 DEFLATE、公共事件固定用 Protobuf，连接 URL 不再带 wire 参数，这里的百分比不能套用到现在；当前实现在 server/src/ws_codec.rs、protocol/realtime.proto 与 client-game/src/services/wsCodec.ts。