Checksum帧用于状态一致性校验：在关键逻辑帧（如每10帧或技能结算帧）生成确定性校验和，客户端用定点数、整数运算、固定顺序容器和固定种子随机数独立计算并上报，服务端比对不一致即触发Desync检测，结合PredictMismatch连续3帧异常定位回滚起点。
怎么用 Checksum 帧做状态一致性校验
帧同步最怕的不是延迟，而是客户端之间逻辑跑偏——同一帧输入下，A 客户端算出角色 X=10.5，B 客户端算出 X=10.499999，后续所有帧全错。这种差异必须在早期捕获，否则回滚代价极大。
核心做法是在关键逻辑帧（比如每 10 帧或每技能结算帧）生成一个确定性校验和，所有客户端独立计算并上报给服务端比对。校验和不能依赖浮点数直接哈希，而要基于定点数、整数位运算、固定顺序容器遍历等可复现方式。
-
FixedFloat类型必须参与校验，float类型一律禁止出现在逻辑层 - 容器遍历必须用
std::vector+ 索引循环，禁用std::unordered_map（哈希顺序不可控） - 随机数必须用固定种子的
std::mt19937，且每次调用前显式seed() - 校验和建议用
uint32_t异或累加，而非std::hash（标准库 hash 不跨平台）
如何识别 Desync 并触发最小化回滚
单纯比对 Checksum 只能告诉你“已经不同步”，但无法定位哪一帧开始出错。真正实用的检测需结合两种信号：
- 服务端收到两个客户端上报的同一帧
Checksum不一致 → 触发DesyncDetected(FrameID)事件 - 客户端本地预测执行时，发现服务端下发的
player_keyboards[FrameID]与自己上帧缓存的输入不匹配 → 立即标记该帧为PredictMismatch
注意：单次 PredictMismatch 不代表必然 Desync（可能是网络抖动导致指令乱序），但连续 3 帧都 mismatch，就必须强制回滚到最近的 Snapshot Frame（带完整对象状态的快照帧）并重放。
立即学习“C++免费学习笔记（深入）”；
为什么 GetKeyState 不能直接用于反作弊逻辑校验
有人想用 GetKeyState(VK_SHIFT) 检测“是否按了 Shift”来辅助判断操作合法性，这是危险的。因为：
-
GetKeyState返回的是 Windows 消息队列当前快照，不是游戏逻辑帧内采样的输入 —— 它可能比逻辑帧早或晚几十毫秒 - 外挂完全可 hook 该 API 并伪造返回值，服务端无法验证
- 真正的反作弊输入校验必须绑定到逻辑帧：比如在
FrameSyncManager::LogicUpdate()开始时调用CollectInput()，且该函数只读取本地输入缓冲区（由WndProc或Raw Input预先填充并时间戳对齐）
换句话说：GetKeyState 可用于 UI 层快捷键响应，但绝不能作为帧同步逻辑的输入源或校验依据。
服务端仲裁模式下怎么设计轻量级校验点
纯客户端帧同步反作弊弱，但全切状态同步又太重。折中方案是“服务端仲裁帧同步”：服务端不运行完整逻辑，只在关键节点做确定性裁决。此时校验点设计要克制：
- 只在技能命中判定、碰撞检测、伤害结算三类节点插入
ServerValidateHit(FrameID, attackerID, targetID, hitPos) - 客户端提交这些事件时，必须附带完整的输入上下文（前 3 帧的
player_keyboards+ 当前帧FixedFloat状态快照） - 服务端用相同定点数逻辑重演这 3 帧，仅校验该事件是否成立，不校验全过程
- 失败则下发
RollbackTo(FrameID-3)，客户端丢弃后续帧并重放
这种模式把服务端计算量控制在 5% 以内，却能堵住 80% 的常见外挂路径 —— 关键在于校验点不能贪多，必须选在“结果影响大、逻辑分支少、复现成本低”的位置。
