在我们开发单机游戏时，使用 float 类型来计算是非常常见的，但是当涉及到帧同步网络开发时，传统帧同步不传状态，但是必须可被确定性推导/哈希校验，此时float 类型的精度问题可能会导致不同客户端之间的计算结果不一致。

前九章分别讨论了 Ability、Attribute、Gameplay Effect、Target Data、Server Authority 和客户端预测。

你数据上传失败了吗？

上一章把信任边界放在服务器：客户端提交 Request，服务器验证并构造 Command，最终由服务器提交公共战斗事实。但如果客户端在收到 Result 之前完全不动，玩家会明显感到网络往返延迟。

多人游戏里最容易被误解的一句话，就是“服务器权威”。有人把它理解成：所有逻辑都在服务器执行，客户端只负责发按钮和等结果。这个方案确实容易解释，但实际操作起来会让每一个技能都经历明显的输入延迟。玩家按下火球术，等服务器收到请求、完成校验、广播结果，客户端才开始播放起手动画；在高延迟网络下，技能会像“按了但没反应”。

上一章已经让 Tag、Attribute 和 Effect 拥有了明确来源与生命周期。 但一次火球术并不是同步执行到底的函数。它可能等待：

上一章建立了五层架构。Definition 保存火球术的静态参数，Runtime 保存角色当前状态，Simulation 负责检查、Commit 和 Effect 推进。现在需要回答更具体的问题：

上一章已经把一次 Ability 拆成输入请求、激活检查、Commit、Target Data、Effect 结算、取消与结束六个阶段。现在准备在 Unity 中落地时，最容易走偏的第一步，是打开 IDE 创建一组与 UE 同名的 C# 类：

玩家按下火球术快捷键，客户端立刻播了抬手动画，火球看着已经释放出来了——但服务器那边，可能发现施法者没有这个技能，可能 Mana 不够，可能冷却尚未结束，也可能客户端锁定的目标早已死亡。就算请求全部合法，后面还有投射物飞行、命中结算、持续灼烧、中途被打断和生命周期清理。

第一次接触 GAS，最直观的感受往往是：一个火球术为什么要拆出这么多对象？