UE5 里做 RPG，角色移动这块迟早要面对一个岔路口：是继续用输入系统直接驱动 CharacterMovement，还是把移动指令也纳入 GAS（Gameplay Ability System）的管辖范围。我见过不少项目前期图省事，直接在 PlayerController 里监听鼠标点击然后调AddMovementInput，跑起来确实快，但等到要加"被定身""移动消耗耐力""不同姿态移速不同""技能位移打断普攻"这些需求时，代码就开始到处打补丁，最后移动逻辑散落在四五个文件里，改一个数值要全局搜索。这篇就聊怎么把鼠标点击移动完整地做成一个 GAS Ability，让移动指令和技能系统共用同一套标签、消耗和冷却机制。

核心关键词是UE5、GAS、鼠标点击移动、AbilityTask、NavMesh。适合已经搭好 GAS 基础框架（ASC、AttributeSet、GameplayAbility 基类都跑通了）、想把手游或端游 RPG 的点击寻路移动接入技能系统的开发者。如果你还在纠结 GAS 要不要上，那这篇可以先收藏，等基础跑通再回来看。下面所有内容都是基于常见工程实践给出的方案，具体数值和类名按你项目实际情况调整。

1. 为什么点击移动值得单独做成一个 Ability

1.1 直接驱动 CharacterMovement 的隐性成本

先说清楚问题在哪。最常见的写法是在 PlayerController 的SetupInputComponent里绑定鼠标左键，按下时做一次射线检测拿到世界坐标，然后调GetNavAgentLocation配合UNavigationSystemV1::SimpleMoveToLocation，或者干脆自己算方向向量喂给AddMovementInput。这套流程在单人 Demo 里毫无问题，但它绕过了 GAS 的整个决策层。

绕过的代价体现在几个地方。第一，状态互斥失效。角色被眩晕时你希望移动指令直接无效，但如果移动走的是输入直连，你就得在输入回调里手动查一遍HasMatchingGameplayTag(State.Stunned)，而这个查询散落在每个输入回调里，漏一个就是 bug。第二，消耗与冷却无处挂载。冲刺移动要扣耐力、某些地形移动要触发 debuff，这些在 GAS 里本来是 Cost 和 Cooldown 的标准职责，直连方案只能自己写计时器和属性扣减，重复造轮子。第三，网络同步要自己兜底。GAS 的 Ability 激活走的是服务器权威的预测模型，客户端预测、服务器校验、失败回滚都是现成的；直连方案在多人环境下要么接受客户端作弊风险，要么自己写一套 RPC 校验。

所以把点击移动做成 Ability，本质不是"为了用 GAS 而用 GAS"，而是把移动这个高频行为纳入统一的标签门控 + 消耗结算 + 预测同步体系。一旦纳入，后面加"移动时禁止施法""施法时禁止移动""不同装备改变移速"这些交叉规则，就变成了标签配置问题，而不是代码逻辑问题。

1.2 点击移动 Ability 的职责边界

需要明确一点：这个 Ability 不负责"怎么走"的底层寻路，它负责的是"能不能走、走的时候扣什么、什么时候算走完"。底层寻路仍然交给 NavMesh 和 CharacterMovement，Ability 只是发号施令并监听结果。

我把它拆成三层职责。决策层是 Ability 本身，判断当前是否允许移动（标签、消耗、冷却），激活后进入移动状态。执行层是 AbilityTask，负责发起寻路请求、监听移动完成或中断、把结果回调给 Ability。表现层是动画蓝图和角色朝向，根据速度驱动 BlendSpace，这部分和 GAS 无关，但要在移动状态切换时收到通知。

这个边界划清楚之后，代码结构就顺了：Ability 里不写一行寻路代码，Task 里不写一行标签判断，各司其职。下面几节按这个分层展开。

2. 环境与前置条件：别急着写 Ability，先把这几样确认了

2.1 GAS 基础链路自检清单

动手之前先过一遍清单，任何一项没通，后面都会卡住。ASC 的归属要确认清楚：玩家角色自己持有 ASC 还是挂在 PlayerState 上。点击移动涉及预测，如果 ASC 在 PlayerState 上，要确保OwnerActor和AvatarActor设置正确，否则 Task 里拿AvatarActor会拿到空。GameplayAbility 基类要有一个项目自己的父类，里面封装好ActivateAbility的模板流程和常用工具函数，别每个 Ability 都从原生类继承。GameplayTag 表要提前规划好移动相关的标签，至少包括Ability.Move.Click（Ability 自身标签）、State.Moving（移动状态）、Block.Move（禁止移动的阻断标签）。InputTag 映射如果用 Enhanced Input，Ability 的激活标签要和 InputAction 的 AssetTag 对上。

还有一项容易被忽略：AbilitySystemComponent 的ActivateAbilityByTag调用链要确认可用。点击移动的激活入口通常是输入触发，走AbilitySystemComponent->TryActivateAbilityByTag，这条链路要确保 InputTag 已经注册到 ASC 的AbilityInputBindings里，否则标签激活会静默失败，调试时很难发现。

2.2 NavMesh 与角色胶囊体的匹配细节

点击移动依赖 NavMesh，而 NavMesh 的生成参数直接决定点击体验。Agent Radius要略大于角色胶囊体半径，否则角色会贴着墙走然后卡住；Agent Height要覆盖角色高度加上一点余量；Max Slope和Step Height按你关卡的地形来，RPG 里如果有台阶和斜坡，Step Height 给到 45 左右比较稳。这些参数在 Project Settings 的 Navigation Mesh 里配，改完记得重新 Build。

还有一个实操细节：点击位置到 NavMesh 的投影。玩家点的地方可能在墙外、在空中、在不可行走区域，直接拿射线命中点去寻路会失败。正确做法是用UNavigationSystemV1::ProjectPointToNavigation把命中点投影到最近的可行走点，投影半径给个 200 到 500，超出范围就判定为无效点击，直接不激活 Ability。这个判断放在 Ability 激活前的CanActivateAbility里做，比激活后再失败要干净。

提示：ProjectPointToNavigation 的 Extent 参数是盒体范围，Z 轴要给足，否则俯视角下点击地面可能投影失败。俯视角 RPG 建议 Z 给 1000 以上。

2.3 输入到 Ability 的触发路径

Enhanced Input 下，鼠标左键的 InputAction 配一个Ability.Move.Click的 AssetTag，然后在 ASC 里绑定这个标签到对应的 Ability。触发方式建议用Triggered而不是 Started，因为点击移动是"按住持续移动、松开停止"还是"点一下走一段"，取决于你的设计。如果是点一下走一段（经典 RPG），用 Started 触发一次激活即可；如果是按住移动，需要在 Released 时通知 Ability 停止，这就要在 Ability 里监听输入释放事件。

我倾向于点一下走一段的方案，因为它和 GAS 的"激活-完成"生命周期更契合，Ability 激活后自己管自己的结束条件，不需要额外监听输入释放。按住移动的方案需要 Ability 常驻激活状态，输入释放时手动EndAbility，状态管理更复杂，除非你的游戏明确需要，否则不建议。

3. 用 AbilityTask 封装寻路请求与完成回调

3.1 为什么必须用 AbilityTask 而不是在 Ability 里直接寻路

有人会问：寻路就一行SimpleMoveToLocation，为什么还要包一层 Task？原因在于异步性。寻路是异步的，移动过程是持续的，Ability 需要知道"什么时候走到了""什么时候被打断了""什么时候寻路失败了"，这些事件不在激活那一刻发生，而在之后的若干帧里陆续到来。Ability 的ActivateAbility是一个同步函数，它返回之后就没法再"等待"了，除非你用 Task 把异步事件桥接回来。

AbilityTask 的本质是一个 UObject，它持有 Ability 的弱引用，在Activate时发起异步操作，在异步回调里通过委托通知 Ability，Ability 收到委托后决定是继续还是EndAbility。这套机制是 GAS 处理所有持续性行为的标准范式，点击移动只是其中一个应用。不用 Task 而用 Tick 轮询"是否到达"，既浪费性能又难处理中断，是典型的反模式。

3.2 Task 的类结构与关键成员

Task 继承UAbilityTask，核心成员包括：一个MoveCompleted的动态多播委托（走到目的地时广播）、一个MoveInterrupted委托（被打断时广播）、保存目标位置的FVector TargetLocation、保存寻路结果的FNavLocation、以及一个标志位记录是否已结束避免重复广播。

Activate函数里做三件事：拿AvatarActor转成 ACharacter 或 APawn、调UNavigationSystemV1::SimpleMoveToLocation发起寻路、把自身注册到某个管理器或直接靠 Tick 检测完成。这里有个坑：SimpleMoveToLocation内部走的是 AIController 的 MoveTo，如果角色没有 AIController（玩家角色通常没有），这个调用会失败。所以玩家角色的点击移动不能直接用 SimpleMoveToLocation，要么给玩家角色挂一个轻量 AIController，要么自己用UNavigationSystemV1::FindPathToLocationSynchronously算路径再喂给 CharacterMovement。

我实测下来更稳的方案是后者：用FindPathToLocationSynchronously拿到FNavigationPath，然后自己沿路径点驱动AddMovementInput，或者用UAIBlueprintHelperLibrary::CreateMoveToProxyObject创建一个移动代理。前者控制力最强但代码多，后者省事但依赖 AI 模块。中小项目建议用移动代理，大项目建议自己算路径，因为要处理路径点平滑和动态障碍。

3.3 完成检测的两种思路与取舍

思路一：距离阈值检测。Task 在 Tick 里算角色到目标点的水平距离，小于阈值（比如 50）就判定到达，广播MoveCompleted。优点是简单、不依赖寻路系统回调；缺点是如果路径被堵、角色原地打转，距离永远不达标，Task 会一直挂着。需要加一个超时机制，比如激活后 30 秒还没到就强制结束并广播中断。

思路二：监听 CharacterMovement 的移动完成。CharacterMovement 在路径走完时会触发OnMovementModeChanged或速度归零，Task 监听这些事件判断完成。优点是语义准确；缺点是要处理各种边界情况，比如角色被击退导致速度短暂归零会被误判为到达。

我一般用思路一为主、思路二为辅：主循环用距离阈值，同时监听速度，如果速度持续为零超过 0.5 秒且距离未达标，判定为卡住，广播中断。这个组合能覆盖绝大多数情况，包括被障碍物挡住、被其他角色挤开等。

// Task 的 Tick 简化逻辑 void UAbilityTask_ClickMove::TickTask(float DeltaTime) { if (!CachedCharacter.IsValid()) { EndTask(); return; } const FVector Current = CachedCharacter->GetActorLocation(); const float DistSq = FVector::DistSquared2D(Current, TargetLocation); if (DistSq < AcceptanceRadius * AcceptanceRadius) { MoveCompleted.Broadcast(); EndTask(); return; } if (CachedCharacter->GetVelocity().SizeSquared2D() < 1.0f) { StuckTimer += DeltaTime; if (StuckTimer > StuckThreshold) { MoveInterrupted.Broadcast(); EndTask(); } } else { StuckTimer = 0.0f; } }

3.4 Task 的清理与防泄漏

Task 结束时要确保委托被清空、Tick 被关闭、对 Character 的引用被释放。EndTask里调Super::EndTask之前先把MoveCompleted.Clear()和MoveInterrupted.Clear()做掉，否则 Ability 已经 End 了但 Task 还持有委托，下次激活时旧委托可能被误触发。另外 Task 要设置bTickingTask = true并在Activate里调SetWaitingOnAvatar或类似机制，确保 Avatar 销毁时 Task 自动结束，避免悬空指针。

4. Ability 本体的激活门控与状态标签管理

4.1 CanActivateAbility 里该查什么

CanActivateAbility是门控的第一道关，查的东西要精准，别把运行时才该判断的逻辑塞进来。我通常查三类：标签阻断，用ActivationBlockedTags配Block.Move，被定身、被眩晕时这个标签存在，Ability 直接激活失败；已有实例，如果移动 Ability 是单实例的（InstancingPolicy = InstancedPerActor），要确认当前没有正在跑的移动；目标有效性，把点击位置投影到 NavMesh 的结果作为参数传进来，投影失败直接返回 false。

注意CanActivateAbility里不要做消耗检查，消耗由 GAS 在激活流程里自动处理（Cost GE 的施加和回滚）。也不要在里面做冷却检查，Cooldown GE 同理。这两样交给框架，你只管业务门控。

4.2 激活后的状态标签施加与移除

Ability 激活成功后，第一件事是给自己加State.Moving标签，用AddLooseGameplayTag或通过 GE 施加。用 Loose Tag 更轻量，但要注意配对移除，否则标签泄漏会导致后续所有移动被阻断。我习惯在ActivateAbility里加标签，在EndAbility里移除，并且用bIsEnding标志位防止重复移除。

State.Moving这个标签的用途很广：动画蓝图可以查它切换移动状态，其他 Ability 可以用BlockAbilitiesWithTag在移动时禁止某些技能，UI 可以查它显示移动指示器。所以这个标签的命名要规范，放在State命名空间下，别和Ability命名空间混。

4.3 移动被打断时的收尾逻辑

打断来源有很多：玩家点了新位置（旧 Ability 要先 End 再激活新的）、角色被击退、角色死亡、关卡切换。每种来源的收尾逻辑不同，但共同点是必须保证EndAbility被调用且标签被移除。

处理"点新位置"这种打断，最干净的做法是在激活新 Ability 前先CancelAbilitiesWithTag(Ability.Move.Click)，让旧 Ability 走正常的取消流程。EndAbility里判断WasCancelled，如果是取消，广播中断委托、清理 Task、移除标签。这样新旧交替不会出现两个移动 Task 同时跑的情况。

角色死亡这种打断，靠Block.Move标签实现：死亡时施加这个标签，移动 Ability 的ActivationBlockedTags命中，新激活被拒；同时死亡流程里主动CancelAbilitiesWithTag，把正在跑的移动取消掉。两条路都要走，只靠标签只能阻止新激活，阻止不了已经在跑的。

5. 鼠标射线检测与目标点投影的完整链路

5.1 从屏幕坐标到世界坐标的射线

鼠标点击的起点是屏幕坐标，要转成世界射线需要DeprojectScreenPositionToWorld，传入鼠标的屏幕位置和 PlayerController，输出射线原点和方向。然后做LineTraceByChannel，通道用Visibility或自定义的ClickTrace通道，忽略角色自身。

这里有个细节：射线长度。用TraceMaxDistance给个 10000 到 50000 之间，太短了俯视角点远处会打空，太长了可能命中天空盒。俯视角 RPG 建议 50000，第三人称建议 10000。命中结果里取ImpactPoint作为候选目标点。

如果射线什么都没命中（点到天空），直接判定无效，不激活 Ability。这一步在 PlayerController 或 Character 的输入回调里做，做完把有效坐标传给 Ability 激活参数。

5.2 投影到 NavMesh 的容差与失败处理

拿到ImpactPoint后，用ProjectPointToNavigation投影。投影的Extent是个盒体，X/Y 给 200 到 500，Z 给 1000 以上（俯视角）。投影成功返回FNavLocation，取Location作为最终目标点；投影失败说明点击位置附近没有可行走区域，直接不激活。

投影半径的选择是个权衡：给太小，玩家点在地形边缘会频繁失败，体验差；给太大，玩家点在墙外可能被投影到墙内，角色走过去撞墙。我的经验是X/Y 给 300 左右，配合 NavMesh 的 Agent Radius 略大于胶囊体，能覆盖大部分边缘情况。如果你们的关卡地形特别碎，可以适当放大到 500，但要配合"目标点是否可达"的二次校验。

5.3 目标点可达性的二次校验

投影成功不代表可达。目标点可能在孤岛上、在关闭的门后、在高度差过大的平台上。二次校验用UNavigationSystemV1::FindPathToLocationSynchronously算一条路径，如果返回的路径点数量为 0 或路径无效，判定不可达，不激活 Ability。

这个校验有性能成本，每次点击算一次同步寻路，在复杂场景里可能卡顿几毫秒。优化思路是先做廉价校验再做寻路：先用NavigationSystem->GetNavDataForProps确认目标点在 NavMesh 覆盖范围内，再算路径。另外可以把寻路结果缓存一小段时间，连续点击同一区域时复用。

注意：FindPathToLocationSynchronously 在主线程执行，复杂场景下慎用。如果关卡很大，考虑改成异步寻路，用 AsyncTask 或 NavigationSystem 的异步接口，把结果回调给 Ability 激活流程。

6. 移动表现层：朝向、动画与速度的联动

6.1 角色朝向的平滑旋转

点击移动时角色要转向移动方向，但直接SetActorRotation会瞬移式转向，很生硬。正确做法是在 Character 的 Tick 或 CharacterMovement 的旋转设置里做插值。CharacterMovement 有个bOrientRotationToMovement开关，打开后会自动朝速度方向旋转，配合RotationRate控制转速。RPG 里RotationRate的 Yaw 给 540 到 720 度每秒比较自然，太快像陀螺，太慢像拖拽。

如果角色在移动中要面向目标（比如边退边打），就不能用bOrientRotationToMovement，要改成bUseControllerRotationYaw配合手动插值。这种混合场景建议在 Ability 里根据标签切换旋转模式，移动 Ability 激活时开bOrientRotationToMovement，战斗 Ability 激活时关掉。

6.2 动画蓝图如何感知移动状态

动画蓝图不该直接查 Ability 是否激活，而应该查State.Moving标签或 Character 的速度。查标签的方式是在 AnimBP 的NativeUpdateAnimation里通过 ASC 查HasMatchingGameplayTag，但 AnimBP 拿 ASC 要走 Character 的接口，耦合略重。更轻的方式是查GetVelocity().SizeSquared2D()，速度大于阈值就进移动 BlendSpace，小于就进待机。

两种方式各有适用场景：查速度简单直接，但区分不了"被击退的移动"和"主动移动"；查标签精确，但要处理标签同步。我一般速度驱动动画、标签驱动逻辑，动画层不关心移动是怎么来的，只关心当前速度多少，这样动画和 GAS 解耦，换移动方案不用改动画。

6.3 移动速度的属性化改造

硬编码移速是 RPG 大忌。移速应该来自 AttributeSet 里的MoveSpeed属性，CharacterMovement 的MaxWalkSpeed在 Tick 里同步这个属性值。这样装备、buff、地形都能通过修改属性影响移速，GAS 的 GE 系统天然支持这种修改。

同步的时机要注意：不要在 Ability 里直接改MaxWalkSpeed，而是改属性，让属性变化驱动MaxWalkSpeed。可以在 Character 的 Tick 里做GetCharacterMovement()->MaxWalkSpeed = GetAttributeSet()->GetMoveSpeed()，或者用属性变化委托回调。后者更高效，但要注意初始化顺序，属性还没初始化时回调可能拿到 0。

7. 联机环境下的预测与回滚要点

7.1 客户端预测移动的边界

GAS 的预测机制对移动 Ability 的支持有个前提：预测的只是 Ability 的激活和标签，不是实际的位移。位移本身由 CharacterMovement 的移动复制负责，这部分是引擎原生的客户端预测 + 服务器校正。所以移动 Ability 的预测要关注的是"激活是否被服务器认可"，而不是"位置是否同步"。

具体来说，客户端点击后本地预测激活 Ability、加State.Moving标签、发起寻路；服务器收到激活请求后校验标签和消耗，认可则复制激活，不认可则回滚客户端的标签。位移由 CharacterMovement 自己同步，和 Ability 无关。理解这个分工，就不会在 Ability 里手动同步位置。

7.2 服务器校验失败时的表现处理

服务器拒绝激活的常见原因：消耗不足（耐力不够）、标签阻断（服务器认为角色被定身）、冷却未好。客户端预测激活后角色已经开始走了，服务器拒绝后要回滚，表现为角色突然停下、标签消失。这个体验很突兀，缓解办法是客户端激活前做一次本地预校验，把消耗、标签、冷却都查一遍，本地不通过就不预测激活，直接给 UI 反馈（比如耐力不足的提示）。

本地预校验不能完全替代服务器校验，但能过滤掉大部分明显失败的情况，减少回滚带来的突兀感。预校验的逻辑放在CanActivateAbility里，查HasMatchingGameplayTag和属性的当前值，注意查的是预测值而不是服务器值，GAS 的预测属性系统会自动处理这个。

7.3 移动中断的复制一致性

移动被打断时，客户端和服务器要同时结束 Ability。如果客户端因为本地原因（比如点了新位置）取消，要发 RPC 通知服务器取消；如果服务器因为游戏逻辑（比如被眩晕）取消，要复制到客户端。GAS 的CancelAbility走的是预测取消流程，客户端取消会先本地回滚再通知服务器，服务器取消会复制到客户端。

要小心的是取消的时序：客户端取消后立刻激活新移动，服务器可能还没处理完旧移动的取消，导致新移动的激活被旧移动的标签阻断。解决办法是在客户端取消旧 Ability 后，等一帧再激活新的，或者用CancelAbilitiesWithTag让框架处理时序。实测下来CancelAbilitiesWithTag后立即TryActivateAbilityByTag在多数情况下没问题，但网络延迟高时偶发失败，加一个短延迟（0.05 秒）更稳。

8. 调试与常见故障排查

8.1 点击无反应的排查顺序

点击没反应是最常见的反馈，排查要按链路从前往后走。第一步查输入：在输入回调里打日志，确认鼠标点击事件到了、射线做了、命中点拿到了。第二步查投影：打印ProjectPointToNavigation的返回值和投影后的坐标，确认投影成功。第三步查激活：打印TryActivateAbilityByTag的返回值，false 的话查CanActivateAbility里哪一项没过，把标签、消耗、冷却逐个打印。第四步查寻路：Task 激活后打印寻路结果，确认路径点数量大于 0。

这个顺序能覆盖 90% 的"点击无反应"。剩下 10% 通常是 ASC 配置问题，比如 Ability 没 Give、InputTag 没绑定、ASC 的InitAbilityActorInfo没调。用showdebug abilitysystem控制台命令能看到当前 ASC 的所有标签和激活的 Ability，是排查这类问题的利器。

8.2 角色走到一半停住的几种原因

走到一半停住，原因可能是：寻路路径被动态障碍阻断，比如门关了、其他角色挡路，CharacterMovement 的路径跟随会停；AcceptanceRadius 设太大，角色在离目标还有一段距离时就判定到达；Task 的卡住检测误判，角色短暂减速被当成卡住；NavMesh 动态更新导致路径失效。

排查时先看角色停住的位置和目标点的距离，如果距离还远，多半是路径问题；如果距离很近，多半是 AcceptanceRadius 或卡住检测的问题。动态障碍导致的停住，需要在 Task 里监听路径失效事件，重新寻路或广播中断。这部分建议加日志，把每次停住的原因打出来，方便定位。

8.3 标签泄漏导致的"永久定身"

标签泄漏是 GAS 项目里最隐蔽的 bug 之一。表现是角色某次被打断后再也走不了，查标签发现Block.Move或State.Moving一直挂着。原因通常是EndAbility没被调用，或者调用了但移除标签的代码在某个分支被跳过。

防御手段有三层：第一，EndAbility里用ensure或日志确认标签被移除；第二，在 Character 的 Tick 里做一次标签健康检查，发现State.Moving存在但没有任何移动 Ability 在跑，强制移除；第三，用showdebug abilitysystem定期检查标签状态。第三层是开发期手段，前两层是运行期兜底。

提示：Loose GameplayTag 不会随 Ability 结束自动移除，必须手动配对。用 GE 施加的标签会随 GE 移除自动清理，但 GE 有额外的开销。高频的移动状态标签建议用 Loose Tag 加手动管理，低频的状态标签用 GE。

9. 性能与扩展性：这套方案能撑到什么规模

9.1 每次点击的寻路开销评估

单次点击的完整链路包括：射线检测（一次 LineTrace）、投影（一次 ProjectPointToNavigation）、可达性校验（一次同步寻路）、Task 激活（一次寻路）。其中同步寻路是开销大头，复杂场景下单次可能 1 到 5 毫秒。玩家正常点击频率是每秒 1 到 3 次，这个开销可以接受；但如果是 RTS 那种框选大量单位移动，就不能每个单位算一次同步寻路，要用异步寻路加路径共享。

RPG 场景下还有个优化点：连续点击同一区域时复用寻路结果。可以在 PlayerController 里缓存上一次的点击位置和寻路结果，如果新点击位置在旧目标点附近（比如 100 单位内），直接复用路径，跳过同步寻路。这个优化在玩家反复点同一方向时效果明显。

9.2 大量单位移动时的 Task 管理

如果游戏里有召唤物、队友 AI 也走这套点击移动，Task 的数量会上去。每个 Task 都在 Tick，几十个单位同时移动时 Tick 开销不可忽视。优化思路是降低 Tick 频率：Task 不需要每帧检测距离，可以每 3 到 5 帧检测一次，用SetTickInterval或自己累计时间。移动完成检测的精度要求不高，5 帧的延迟玩家感知不到。

另一个思路是用事件驱动替代轮询：CharacterMovement 在路径走完时会触发OnMovementModeChanged，Task 监听这个事件而不是 Tick 检测距离。事件驱动的开销更低，但要处理边界情况（比如被击退导致的模式切换）。混合方案是 Tick 低频检测加事件监听，两者结合。

9.3 后续扩展：冲刺、跳跃、地形移动

这套框架搭好后，扩展很自然。冲刺是另一个 Ability，激活时施加一个修改MoveSpeed的 GE，同时可能替换移动 Task 为更快的版本。跳跃是独立的 Ability，和点击移动并行，用标签互斥（跳跃时禁止点击移动，或点击移动时禁止跳跃）。地形移动（比如沼泽减速）通过 GE 修改MoveSpeed实现，移动 Ability 本身不用改。

关键是把"移动"和"移动的变体"分开：基础点击移动是一个 Ability，冲刺、传送、击飞是各自的 Ability，它们共享 Task 和标签体系，但激活条件和效果不同。这样加新移动方式时，不用改基础 Ability，只加新的就行。

10. 我在实际项目里踩过的几个坑

第一个坑是SimpleMoveToLocation 对玩家角色无效。早期图省事直接调这个函数，玩家角色没 AIController，调用静默失败，角色纹丝不动，日志里啥也没有。后来改成CreateMoveToProxyObject才跑通。这个坑的教训是：引擎函数的名字有迷惑性，"Simple" 不代表通用，要看它内部依赖什么。

第二个坑是Task 的委托在 Ability 结束后仍被触发。有次角色走到目的地后 Ability 正常 End，但 Task 的 Tick 没停，下一帧又广播了一次MoveCompleted，导致 UI 闪了一下。原因是EndTask里忘了关 Tick。后来在EndTask里统一做清理：清委托、关 Tick、释放引用，三件套一个不能少。

第三个坑是俯视角下投影的 Z 轴范围不够。俯视角相机离地面远，点击地面时射线的命中点 Z 值和 NavMesh 的 Z 值有偏差，ProjectPointToNavigation的 Extent Z 给 500 不够，投影频繁失败。改成 2000 之后稳定。这个参数没有通用值，要按相机高度和地形起伏调。

第四个坑是标签移除的时序问题。移动 Ability 取消后立即激活新移动，旧 Ability 的EndAbility里移除State.Moving的代码在新 Ability 加标签之后执行，把新标签也移除了。解决办法是用引用计数或者确保移除只针对自己加的标签实例。GAS 的 Loose Tag 是布尔式的，没有引用计数，所以要么用 GE 管理，要么在移除前确认没有其他移动 Ability 在跑。

这几个坑的共同点是：框架能帮你做的事比你想的少，边界情况要自己兜。GAS 提供了标签、消耗、预测的骨架，但具体的状态管理、时序处理、清理逻辑，还是得一行行写。把边界情况想全，比把主流程跑通更重要。

最后分享一个调试习惯：给移动 Ability 的每个关键节点打上带前缀的日志，比如[ClickMove] Activate、[ClickMove] TaskStarted、[ClickMove] Completed、[ClickMove] Cancelled，用UE_LOG的 Log 级别而不是 Verbose，这样默认就能看到。出问题时看日志的时间戳，能快速定位是激活失败、寻路失败还是完成检测失败。这个习惯帮我省了大量排查时间，比断点调试高效得多。