问题导入#

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

如果把这些行为都写进一个 CastFireball()，代码表面上很直接，实际却混合了不同责任：

• 输入层负责表达玩家意图；
• Ability 负责组织执行流程；
• 规则层负责检查、扣费和结算；
• 网络层负责请求、确认、拒绝与校正；
• 表现层负责动画、特效、音效和界面反馈。

单机原型可以依赖调用顺序维持这些责任，但多人游戏却必须让每一步都可识别、可拒绝、可重放、可清理。

分阶段不是为了增加仪式，而是为了给权威判定、失败处理和异步生命周期建立明确边界。

4.1 为什么执行链必须分阶段#

一次网络化 Ability 是一段跨帧、跨对象、跨机器的流程，至少要面对三种不确定性。

第一种是状态会变化。客户端按键时看到 Mana 为 40，请求到达服务器前，角色可能已被另一个 Effect 扣掉 20 Mana。客户端本地检查通过，不代表服务器检查也会通过。

第二种是结果会延迟。火球从生成到命中需要时间，期间施法者可能被眩晕，目标可能死亡，投射物可能撞到场景。Ability 不能在发出请求后一直占着一组临时状态却没有结束规则。

第三种是预测会出错。客户端为了手感可以先播放施法动作、显示临时冷却遮罩，甚至生成纯表现用的预测火球；服务器拒绝时，这些变化必须能够被精确撤销，而不是重置整个角色。

因此，六个阶段并不是六个彼此隔绝的函数，而是六个职责边界：

这里的“阶段”是逻辑顺序，不代表 Target Data 到第 4 阶段才第一次出现。它通常已经随第 1 阶段的请求发送，并在第 2 阶段参与服务器验证；第 4 阶段强调的是：经过验证的目标意图如何成为权威执行上下文。

1
玩家输入
2
  |
3
  v
4
[1] 输入请求（表达意图，建立预测记录）
5
  |
6
  v
7
[2] 激活检查（服务器做最终决定）---- 拒绝 -> 拒绝路径（撤销预测）
8
  |
9
  v
10
[3] Commit（扣除 30 Mana，添加 2 秒冷却）
11
  |
12
  v
13
[4] Target Data（验证意图，固化权威发射上下文）
14
  |
15
  v
16
[5] Effect 结算（命中后应用 120 伤害与 5 秒 Burning）
17
  |
18
  v
19
[6] 等待 / 取消 / 结束（统一清理，进入 Ended）

1
Client（预测副本）
2
  TryActivateAbility(SpecHandle, InputPressed)
3
    -> CanActivateAbility：本地快照检查
4
    -> ActivateAbility：创建 Ability Instance，启动 Task
5
    -> ServerTryActivateAbility（RPC，携带 PredictionKey）
6

7
Server（权威副本）
8
  ServerCanActivateAbility：完整权威检查
9
  ServerCommitAbility -> CommitAbility
10
    -> ApplyCost：扣除 30 Mana
11
    -> ApplyCooldown：添加 2 秒 Cooldown
12
  -> 验证 Target Data，生成权威投射物
13
  -> 命中后应用 GameplayEffect
14
  -> EndAbility / CancelAbility

4.2 阶段一：输入请求#

输入阶段只负责把“玩家想做什么”转换成能力请求，不负责宣布结果。

火球术请求至少需要携带：

1
RequestId
2
AbilityId = Ability.Fireball
3
PredictionKey
4
TargetData
5
ClientTick
6
InputSource

其中 RequestId 用于幂等处理，PredictionKey 用于关联本地预测与服务器结果，ClientTick 用于判断数据是否过期。InputSource 可以记录这是快捷键、手柄、AI 指令还是 Gameplay Event 触发，但它不能绕过后续规则。

客户端此时可以做一次低成本预检查：

• 本地是否已知拥有火球术；
• 本地是否存在明显的 State.Dead、State.Stunned 或 State.Silenced；
• 本地显示的 Mana 是否至少为 30；
• 本地显示的 2 秒冷却是否结束；
• 是否已经取得基本目标输入。

预检查失败时，不必发送一个必然失败的请求。预检查通过时，客户端可以立刻播放抬手动画、进入瞄准态或显示临时冷却反馈，然后发送 AbilityRequest。

权威边界也很明确：客户端权威地表达自己的输入，服务器权威地决定这次输入是否能改变战斗状态。客户端不能在请求中夹带“目标受到 120 伤害”或“Burning 已生效”这样的结论。

在 UE GAS 中，这一阶段对应 TryActivateAbility 入口。输入系统或 AI 调用它时，ASC 先在本地执行一轮 CanActivateAbility，通过后立即以预测方式 ActivateAbility，再通过 ServerTryActivateAbility 把携带 FPredictionKey 的请求发往服务器。FGameplayAbilitySpecHandle 只指向“这个 Actor 拥有的这份能力”，它本身不携带本次目标——目标通过 Target Data 单独传递。

失败路径包括本地预检查失败、请求未发出、请求超时和重复请求。没有进入本地预测时无需额外清理；已经创建预测记录时，超时不能直接当成成功，而应进入等待重试或拒绝清理流程。重复请求的去重规则在第 8 章展开。

4.3 阶段二：激活检查#

服务器收到请求后，需要使用自己的最新状态重新检查。推荐顺序是先做便宜且决定性的检查，再做目标解析、距离和场景查询等较昂贵检查：

1. 请求发送者是否拥有并控制该 Actor；
2. Actor 是否被授予 Ability.Fireball；
3. Required Tags 是否满足，Blocked Tags 是否存在；
4. 是否有至少 30 Mana；
5. Cooldown.Fireball 是否已经结束；
6. 当前是否有互斥 Ability 或输入锁定；
7. Target Data 的结构是否与火球术匹配；
8. 目标是否存在、可被选择且仍然有效；
9. 起点、方向、目标距离和视线是否合理；
10. ClientTick、PredictionKey 和请求窗口是否仍然有效。

本地 CanActivate 和服务器 CanActivate 可以得到不同结果。这不是框架失效，而是预测模型允许的正常分歧。服务器结果到达之前，客户端的 Activated 只表示本地预测执行已开始，不能升级为权威事实。

在 UE GAS 中，这一阶段由 CanActivateAbility 与 ServerCanActivateAbility 承担。前者的检查集中在 Tag 的 Required/Blocked 查询，以及成本、冷却对应 GameplayEffect 的可用性检查；服务器版本在 ServerTryActivateAbility 到达后重新执行同一套检查，并额外验证连接与 Actor 所有权。UE 允许项目覆写这两个函数，但覆写不应破坏“客户端可拒绝、服务器权威决定”的边界。

如果服务器在这一阶段拒绝，火球术尚未 Commit，也没有权威投射物、伤害或 Burning。服务器只需记录拒绝结果并回复同一 RequestId；客户端则根据 PredictionKey 撤销对应预测。重复请求到达时，服务器应重发第一次的相同结论，避免重复扣费或前后返回不同结果。

4.4 阶段三：Commit#

Commit 是从“允许尝试”跨到“正式承担成本与限制”的事务边界。对于本章火球术，它至少包含：

1
Mana -= 30
2
添加 Cooldown.Fireball，持续 2 秒
3
记录 RequestId / PredictionKey 已提交

4.5 阶段四：Target Data#

Target Data 是对目标上下文的结构化描述。对火球术而言，它可以包含：

1
目标 Actor Id（可选）
2
瞄准起点
3
瞄准方向
4
客户端认为的命中点
5
ClientTick
6
PredictionKey

最重要的原则是：Target Data 是客户端意图，不是最终命中结论。

服务器使用 Target Data 前需要重新验证的检查，大多与激活阶段重叠：所有权、Tag、资源与冷却、目标合法性、空间关系。实现上不要让第 4.3 节的检查与这里的验证变成两套复制代码——让激活检查调用统一的目标验证器。这里只补充 Target Data 特有的两项：

1. 形状匹配：提交的数据形状是否符合火球术，而不是把另一个 Ability 的范围或目标类型塞进来；
2. 时效校验：ClientTick 是否过期，PredictionKey 是否在允许窗口。

逻辑上则要区分两种语义：

1
激活检查：这份目标意图是否足以允许本次 Ability 继续？
2
权威执行：服务器最终采用什么起点、方向和目标上下文生成火球？

服务器可以接受客户端方向，但用服务器角色位置修正发射起点；也可以接受目标 Actor，却重新计算从权威挂点到目标的方向。修正后的上下文应成为后续投射物与命中检测的唯一依据。

如果目标在 Commit 前已无效，服务器返回 InvalidTarget，不扣除权威 Mana，也不添加权威冷却。如果 Commit 后目标才死亡，通常不再撤销施法成本；投射物可以继续飞行、自然消失或按项目规则寻找碰撞结果。

在 UE GAS 中，Target Data 是一份 FGameplayAbilityTargetDataHandle，由 Target Actor 收集或由 WaitTargetData Task 等待玩家选择，再通过 ServerSetReplicatedTargetData 送抵服务器。可迁移的通用原则不是照搬这些类型，而是保留“客户端提交目标意图、服务器验证并生成权威上下文”的边界。

4.6 阶段五：Effect 结算#

Commit 决定“这次施法是否付费”，Effect 结算决定“权威命中造成什么结果”。两者不能合并：合法施放的火球可能打空，而一次命中也不能脱离已确认的 Ability 执行凭空出现。

本章火球术的规则变化发生在两个时刻，可以列成一张表：

前两行回答“这次施法是否成立”，后两行回答“这次命中改变了什么”。若把 Cost 与 Cooldown 混进结算流程，容易误以为扣费和伤害发生在同一时刻

投射物命中后，服务器再完成以下流程：

1
权威碰撞或命中事件
2
  -> 确认投射物尚未结算
3
  -> 解析来源与目标 ASC
4
  -> 检查目标当前是否可受伤或免疫
5
  -> 应用 120 点直接伤害
6
  -> 应用 5 秒 Burning
7
  -> 复制 Attribute / Tag / Active Effect 变化
8
  -> 触发命中 GameplayCue

在 UE GAS 中，这一阶段对应 FGameplayEffectSpec 的创建与应用：伤害通过 ApplyGameplayEffectSpecToTarget 进入目标 ASC，周期性结算由 Effect 的 Period 配置驱动，GameplayCue 只负责把“已经确认的命中”映射为表现。客户端可以预测火球轨迹、命中火花或受击停顿，但不应把其他玩家的最终 Health 与持续 Effect 预测为不可撤销事实。

失败路径主要有三类：

• 投射物未命中：结束命中等待，不应用 Direct Damage 和 Burning；
• 目标在命中时无效或免疫：记录未结算原因，播放对应反馈；
• 重复命中回调：通过投射物结算标记或 Effect 唯一键保证只结算一次。

结算结束后，权威投射物可以销毁，命中等待 Task 可以完成，但 2 秒冷却和 5 秒 Burning 各自继续按照 Effect 生命周期运行。Ability 结束不等于它产生的所有 Effect 都立即结束。

4.7 阶段六：异步等待、取消与结束#

1
Completed：流程正常完成
2
Cancelled：流程开始后被主动或被动中断
3
Rejected：预测执行已经开始，但服务器拒绝权威激活

4.8 服务器确认#

下面的文本时序把“施法被服务器接受”和“火球最终命中”分开。确认请求时，服务器承诺的是这次 Ability 已合法 Commit 并生成权威执行对象；命中仍要等待后续权威碰撞。

1
玩家
2
  -> Client ASC：按下火球术
3

4
Client ASC
5
  -> Client CanActivate：本地检查通过
6
  -> Client Ability：进入 Activated（预测）
7
  -> Presentation：播放抬手、显示预测火球/临时冷却
8
  -> PredictionJournal：记录 PredictionKey = P42
9
  -> Server ASC：发送 AbilityRequest
10
       Ability.Fireball
11
       TargetData
12
       ClientTick
13
       PredictionKey = P42
14

15
Server ASC
16
  -> 验证连接与 Actor 所有权
17
  -> 验证 Ability 已授予
18
  -> 验证 Required / Blocked Tags
19
  -> 验证 Mana >= 30
20
  -> 验证 Cooldown.Fireball 已结束
21
  -> 验证目标、距离与视线
22
  -> 验证 ClientTick、RequestId、PredictionKey
23
  -> Server Ability：进入 Activated
24
  -> Commit：
25
       Mana -= 30
26
       添加 Cooldown.Fireball（2 秒）
27
       状态进入 Committed
28
  -> 固化权威发射起点与方向
29
  -> Projectile：生成权威火球
30
  -> Client ASC：返回 Confirm(P42, 权威状态增量)
31

32
Client ASC
33
  -> PredictionJournal：Confirm(P42)，删除可逆日志
34
  -> 使用权威 Mana / Cooldown 校正本地显示
35
  -> Presentation：保留已播放的抬手，绑定权威火球表现
36

37
稍后，Server Projectile
38
  -> 命中目标
39
  -> Target ASC：应用 120 点直接伤害
40
  -> Target ASC：应用 Burning（5 秒，每 1 秒触发一次）
41
  -> Clients：复制属性、Tag、Active Effect 与 GameplayCue
42

43
Server / Client Ability
44
  -> 停止等待 Task
45
  -> 清理临时上下文
46
  -> EndAbility
47
  -> 状态进入 Ended

这条时序中，四个生命周期词各自出现于不同位置：

1
CanActivate 通过
2
  != 已 Activated
3
  != 已 Committed
4
  != 已 Ended

客户端可能先进入预测 Activated，服务器随后才进入权威 Activated。服务器 Commit 后能力处于 Committed，但直到等待完成或取消后才 Ended。火球命中也不是 Committed 的同义词。

4.9 服务器拒绝#

假设客户端按键时锁定了一个敌人，但请求到达服务器前，该目标已经死亡、离开可选范围或其 Actor Id 已失效。客户端仍可能因为旧快照通过本地预检查并播放预测表现，服务器必须以自己的状态拒绝。

1
玩家
2
  -> Client ASC：按下火球术
3

4
Client ASC
5
  -> Client CanActivate：本地检查通过
6
  -> Client Ability：进入 Activated（预测）
7
  -> Presentation：播放抬手、显示预测准星与预测火球
8
  -> Input：锁定施法相关输入
9
  -> PredictionJournal：Begin(P43)
10
  -> Server ASC：发送 AbilityRequest(P43, Target = Actor 42)
11

12
Server ASC
13
  -> 验证所有权、Ability、Tag、Mana、Cooldown：通过
14
  -> 验证 Target Data：
15
       Actor 42 已死亡 / 不可选 / 超出有效范围
16
  -> 返回 Reject(P43, InvalidTarget)
17
  -> 不 Commit
18
  -> 不扣除权威 Mana
19
  -> 不添加权威 Cooldown
20
  -> 不生成权威投射物
21
  -> Server Ability：结束拒绝路径
22

23
Client ASC
24
  -> 收到 Reject(P43, InvalidTarget)
25
  -> 停止目标、动画、网络等待 Task
26
  -> 移除 State.Casting / State.Targeting 等临时 Tag
27
  -> 解除本次 Ability 持有的输入锁定
28
  -> 清除 Actor 42 的目标上下文与预测火球
29
  -> PredictionJournal：Reject(P43)，撤销临时 Mana / Cooldown 显示
30
  -> Presentation：淡出预测效果，播放目标无效反馈
31
  -> Client Ability：EndAbility，状态进入 Ended

这条拒绝路径中，客户端曾经 Activated，但从未得到服务器 Committed。因此它只撤销预测表现和临时规则状态，不等待服务器“退款”

撤销预测表现也不等于把画面逐帧倒放。已播放的短抬手动画可以快速过渡到收势，预测火球可以淡出，准星可以恢复；真正必须恢复的是会影响后续规则的本地状态，包括预测 Mana、临时冷却、Tag、输入锁定、目标上下文和预测记录。

把两条时序放在一起对比，六个阶段的行为差异一目了然：