直接发完整坐标会导致带宽爆炸，因1万人每秒20次移动更新即达2.4MB/s；需用delta编码+zigzag+varint压缩偏移量，结合运动预测、关键帧裁剪及客户端插值/外推/回滚容错机制保障平滑体验。
为什么直接发完整坐标会让带宽爆炸
MMORPG 里一个玩家每秒移动更新 10–30 次很常见，如果每次发 float x, y, z（12 字节）+ 时间戳 + ID，按 20 Hz 算就是 240 字节/秒/人。1 万人同时移动就接近 2.4 MB/s 仅移动数据——这还没算朝向、速度、状态变更。实际线上服务端常看到移动包占总下行流量 60% 以上，瓶颈不在 CPU，而在网卡和客户端弱网容忍度。
关键不是“能不能压缩”，而是“客户端能否用丢包、延迟、乱序后的残缺数据，仍平滑还原出合理位移”。
用 delta 编码 + 变长整数替代浮点全量传输
核心思路是：不传绝对坐标，只传相对于上一次确认位置的偏移量（delta），且把 float 转成定点数再差分编码。
- 客户端和服务端共享一个世界格子精度，比如
GRID_SIZE = 0.1f，那么pos.x / GRID_SIZE就是整数格子坐标 - 服务端只发送 delta 格子数，用
varint（如 protobuf 的WriteVarint32）编码：小偏移（±5 格内）只要 1–2 字节 - 朝向用 1 字节量化（256 方向）或更激进的 4-bit（16 方向），足够表现转向趋势
- 示例结构（wire format）：
[entity_id: varint][dx: varint][dy: varint][dz: varint][yaw: uint8]
- 注意：dx/dy/dz 必须有符号，
varint对负数效率差，建议先 zigzag 编码（google::protobuf::ZigZagEncode32）
服务端必须做运动预测与关键帧裁剪
纯 delta 还不够。玩家频繁微调方向时，连续发 10 帧 yaw=1、2、3… 会浪费带宽。服务端需：
- 维护每个玩家的「最近 N 帧运动特征」：是否匀速？是否直线？加速度是否低于阈值？
- 若检测到匀速直线运动，只发起始帧 + 速度向量 + 持续时间，后续帧用插值生成（客户端本地预测）
- 仅当实际轨迹偏离预测 >
0.3f（3 格）或方向突变 > 30° 时，才插入一个关键帧（full state） - 关键帧本身也走 delta 编码，但重置 delta 基准点
这要求服务端有轻量运动模型（不用物理引擎，用 struct MotionState { Vec3 pos; Vec3 vel; float last_update_time; } 即可），且每帧做简单拟合判断。
客户端必须实现插值+外推+回滚三级容错
服务端压缩再狠，网络也不可靠。客户端不能等包齐了再动，必须：
- 收到新 delta 后，立刻用上一帧位置 + 本地插值（lerp）过渡，避免跳跃
- 若连续 200ms 无新包，启动外推（extrapolate）：按最后 vel 和 yaw 继续跑，最多外推 1 秒，超时则停住并标记“lost”
- 若收到旧序号包（比如乱序抵达的第 103 帧，但本地已处理到 105），且偏差 >
1.0f，触发回滚（rewind）：倒退到 102 帧，用新包重放 103→104→105
回滚成本高，所以服务端要配合——给每个移动包加单调递增的 seq_num，并限制最大乱序窗口（如只接受 ±5 帧）。
真正难的不是压多少字节，而是让“压缩”和“容错”在客户端行为上不可感知。很多团队卡在插值曲线不平滑、外推后突然刹车、回滚时角色穿模——这些都得靠真机弱网测试调参，没通用解。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
