游戏积分必须用整数，避免浮点数精度误差；等级实时计算、不存档；多人同步由服务端原子累加并裁定，客户端仅上报动作。
计分逻辑该用整数还是浮点数？
游戏积分必须用 int，别碰 Float 或 double。浮点数在累加、存档、网络同步时会出现精度误差，比如 100.0 + 0.1 可能变成 100.09999999999999，玩家看到分数带小数会直接质疑系统可靠性。
等级计算也得基于整数积分：用除法取整（//）或 math.floor()，别用四舍五入——等级跃迁必须确定、可预测。
- 所有计分变量声明为
int（C#/Java）或number但全程只赋整数值（js/TS） - ui 显示前才做格式化，比如加千分位：
score.toLocaleString() - 存档时直接序列化整数，别存计算过程或中间浮点结果
等级提升触发时机怎么选？
别在每次加分后都调用 checkLevelUp()，尤其当连击、多目标得分频繁发生时，容易重复触发动画、音效甚至成就判定。
正确做法是「延迟合并判断」：缓存当前积分变化量，一帧内只执行一次等级校验。
- unity 中用
EndOfFrame回调统一检查；Web 游戏用requestAnimationFrame节流 - 等级提升函数必须带守卫条件：
if (newLevel > currentLevel)，防止同一级反复进入 - 避免在物理更新（
FixedUpdate）里做 UI 相关的等级逻辑，会导致帧率波动影响判断
存档时积分和等级要不要分开保存？
只存积分，等级必须运行时实时计算。存两个字段等于埋雷：玩家改存档文件只调高等级，系统却按原始积分算回低等级，或者反向错乱。
等级公式要写死在代码里，且全局唯一入口，比如 GetLevelFromScore(int score)，禁止分散在多个地方硬编码 score / 1000 这类表达式。
- 存档数据只含
playerScore字段，读档后立刻调用CalculateLevel(playerScore) - 公式变更（如从每 1000 分升一级改成每 1200 分）只需改一个函数，旧存档自动适配
- 测试时故意把存档里的
playerScore改成负数或极大值，确认等级函数不崩溃、返回合理边界值
多人同步下如何避免计分冲突？
客户端不能自增积分后直接广播，必须由服务端裁定。常见错误是客户端 A 加 50 分、B 同时加 30 分，各自发包，服务端没做并发控制，最终只生效了后到的那个请求。
标准解法是「事件溯源 + 服务端原子累加」：客户端上报动作（如 "kill_enemy"），服务端验证合法性后，在服务端执行 score += reward 并广播最终值。
- 客户端本地显示可用乐观更新（先加再等确认），但必须预留回滚逻辑：收到服务端最终值后，若不一致就强制覆盖
- 服务端存储用原子操作，如 redis 的
INCRBY，或数据库的UPDATE player SET score = score + ? WHERE id = ? - 禁止客户端传最终分数值，只传动作类型和上下文 ID（如击杀的敌人 ID），否则作弊成本极低
等级跃迁这种带副作用的操作（解锁技能、播放特效），一定要等服务端确认后再触发，不然玩家可能看到两次升级动画。