应使用本地推算的帧时间而非服务器时间戳做插值，按固定间隔生成local_frame_time，在按tick_number排序的滑动窗口中选取相邻两帧线性插值，并配合完整物理状态保存与恢复、确定性物理引擎配置实现稳定同步。
用 delta time 做插值，但别直接用网络包里的 timestamp
客户端收到的服务器状态包带的时间戳（server_timestamp）往往不是“该帧本该渲染的时间”，而是“它发出来的时间”。如果直接拿这个时间做插值，网络抖动一来，delta time 就乱跳，角色会忽快忽慢、瞬移或卡顿。
真正该用的是本地估算的“目标渲染时刻”——比如每 16ms 渲染一帧，那就按 local_frame_time = base_time + frame_index * 16 推算，再找最近两个服务端状态包，在它们之间线性插值（Lerp）位置/旋转。这样即使包延迟了，只要没丢太多，插值节奏是稳的。
- 服务端发包必须带单调递增的序列号（
tick_number），而不是依赖时间戳排序 - 客户端维护一个滑动窗口缓存（比如最近 3–5 帧），按
tick_number排序，不按收到时间 - 插值时用
lerp(a, b, alpha)，其中alpha = (local_frame_time - a.tick_time) / (b.tick_time - a.tick_time)，注意分母为 0 的保护
预测 + 回滚（client-side prediction）不是万能的，得配对检测和修正
玩家操作后立刻在本地模拟移动，能掩盖网络延迟，但一旦服务器校验失败（比如撞墙、被击中），就得回滚并重播。问题在于：回滚不是简单地“倒退到上一帧”，而是要精确还原物理状态（刚体速度、碰撞标志、动画进度）。
很多项目只保存位置和朝向，结果回滚后角色脚还在墙里、跳跃高度错乱、动画跳帧——这是因为物理引擎内部状态（如 btRigidBody::getLinearVelocity()、接触点缓存）没同步保存。
- 每次预测前调用
save_state()，把关键物理量（位置、速度、角速度、是否接地）写进环形缓冲区，索引用tick_number - 服务器纠错包里必须带
corrected_tick和完整状态快照，不能只给“你错了，重置为 X,Y,Z” - 回滚后不要直接
setWorldTransform()，而要用setLinearVelocity()+setAngularVelocity()恢复动力学连续性
UDP 丢包不可怕，可怕的是无节制重传和错误的超时判断
游戏同步不用 TCP，因为重传会放大延迟。但很多人误以为“UDP 就是随便发”，结果在高丢包下频繁重发旧状态，导致新包被挤掉、带宽打满、延迟雪球式增长。
真正有效的做法是：只重传“有业务意义”的包（比如关键动作确认、重要事件），且用指数退避 + 最大重试次数；对纯状态同步包，宁可丢弃也不重传——下一帧就覆盖了。
- 给每个包打上
generation_id（随每次发送自增），接收端只接受比当前max_seen_gen大的包 - 心跳包用固定间隔（如 100ms），但状态包发送间隔应略小于物理更新周期（如物理 tick 是 30Hz，状态包发 45Hz），靠冗余抵消丢包
- 超时检测别用固定值（如 “200ms 无响应就断连”），改用 RTT 估算（
smoothed_rtt + 4 * rtt_variance），避免弱网误判
物理引擎不同步？先锁死 fixed timestep 和浮点行为
哪怕客户端和服务端都用 Bullet 或 PhysX，只要编译器、CPU、数学库稍有差异，stepSimulation() 跑十秒后位置可能差出半个角色身位——这不是网络问题，是确定性破了。
根本解法不是“两边尽量一致”，而是强制一致：禁用所有非确定性路径，包括 SIMD 加速、多线程物理、动态精度切换。
- 服务端和客户端必须用完全相同的
btDynamicsWorld::stepSimulation()参数，尤其是fixedTimeStep（如1.0f / 60.0f）和maxSubSteps（设为 1） - 编译时加
-ffloat-store（GCC）或/fp:precise（MSVC），禁用 x87 寄存器扩展精度 - 所有随机数必须走确定性 PRNG（如
XorShift32），物理碰撞回调里禁止调用rand()或std::random_device
物理同步最难的从来不是网络模型，而是让两台机器跑出完全一样的浮点轨迹。这点一旦漏掉，后面所有插值、预测、回滚都在给错误结果打补丁。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
