GAS技能需ASC驱动、GA定义、GE承载、GameplayTag通信四者缺一不可；ActivateAbility是唯一可靠执行入口；TryActivateAbilityByClass仅请求激活；GE须显式Apply；Tag是跨系统状态通信总线；取消逻辑为强制要求。
直接说结论：GAS技能不是“写个函数就能放”，而是要靠AbilitySystemComponent（ASC）驱动、GameplayAbility（GA）定义行为、GameplayEffect（GE）承载效果、GameplayTag做状态通信——四者缺一不可，漏掉任一环，技能就只在蓝图里“动一下”，不产生真实游戏影响。
UGameplayAbility::ActivateAbility 是技能执行的真正入口
很多人以为重写 ExecuteAbility 或 OnGiveAbility 就能控制技能逻辑，其实不是。GAS中技能被正式“触发并开始执行”的唯一可靠入口是 ActivateAbility。它在满足所有前置条件（冷却、资源、权限）后由ASC调用，且只在服务器权威上下文（或客户端预测通过后）执行一次。
- 必须调用
Super::ActivateAbility(...)，否则ASC内部状态（如激活标记、计时器）不会更新，后续取消、同步、回调都会失效 - 不要在这里做耗时操作（如遍历场景Actor），容易卡主线程；高频技能建议用
StartAction()+EndAction()拆分逻辑 - 如果技能需要延迟生效（比如吟唱2秒后炸开），必须用
GetWorld()->GetTimerManager().SetTimer(...)，并在Timer回调里调用实际逻辑，不能靠Delay节点硬等 - 传入的
TriggerEventData可携带自定义数据（如鼠标点击位置、目标Actor），但需确保其序列化支持（继承FGameplayEventData并注册网络复制）
UAbilitySystemComponent::TryActivateAbilityByClass 不能直接调用
新手常在蓝图里拖出 TryActivateAbilityByClass 就以为能放技能，结果发现没反应。根本原因是：这个函数只是“尝试请求激活”，是否真能激活取决于ASC当前状态，而它默认不检查输入合法性、不广播事件、也不处理预测失败回滚。
- 正确做法是先用
GiveAbility把技能加到ASC能力列表，再通过输入系统（如Enhanced Input）绑定到InputAction，最终由ASC内部的ActivateAbility流程统一调度 - 若需代码侧主动触发（如AI决策后放技能），应调用
TryActivateAbility（传入FGameplayAbilitySpecHandle），而不是ByClass版本——后者绕过ASC的能力缓存，容易导致重复添加或找不到实例 - 该函数返回
bool仅代表“请求已提交”，不代表技能已执行；要监听OnAbilityActivated委托才能确认真正激活 - 多人游戏中，客户端调用此函数仅触发预测，服务器会校验；若校验失败（如资源不足），ASC会自动回滚UI和动画状态——前提是你的GA实现了
CancelAbility和GetCooldownTime
GameplayEffect 必须显式Apply，不能靠“自动叠加”
很多GA写完伤害逻辑却打不出伤害，问题往往出在GE没正确Apply。GAS不会自动把GE塞进AttributeSet，更不会“看到Damage标签就扣血”——一切都要你亲手调用 ApplyGameplayEffectToTarget 或 ApplyGameplayEffectToSelf。
yuanfang-skills 的共享设计系统，提供 token CSS 变量、12+ 主题以及可复用的布局类型 HTML 块，供 yuanfang-html-image（以及 fu...）使用。
立即学习“C++免费学习笔记（深入）”；
- GE的持续时间（
DurationPolicy）、叠加规则（StackingType）、属性修改方式（ModifierOp）全在GE资产里配置，C++里只负责触发；改错一个选项，可能让10次攻击只生效1次 - 对敌人Apply GE时，目标ASC必须已初始化且有效；常见坑是敌人刚Spawn出来就立刻Apply，此时ASC还没完成注册，调用直接静默失败
- 瞬时GE（
Instant）适合伤害/治疗，但要注意：若同时Apply多个同类型GE，AttributeSet的PostGameplayEffectExecute只触发一次，需在钩子里遍历Effect.Spec.GetModifiers()手动累加 - 服务端Apply后，客户端不会自动同步GE效果——必须确保GE的
bIsGrantedToExecuted和bIsInhibited状态可复制，且客户端启用了bReplicateGameplayTags
GameplayTag 不是“备注”，而是GAS的通信总线
把Tag当注释写（比如 Ability.Fireball）就废了一半GAS能力。Tag是GAS里唯一跨C++/蓝图/网络/线程安全的状态标识机制，所有关键流程都靠它驱动。
- 技能激活条件（
ActivationRequiredTags）、取消条件（DeactivationBlockedTags）、GE施加条件（ApplicationTagRequirements）全依赖Tag匹配，写错大小写或层级（如State.Deadvsstate.dead）会导致整条链路中断 - UI响应伤害不能绑Health变量，得监听
OnGameplayTagAdded或OnAttributeChanged的Tag事件；例如暴击反馈应监听Damage.Critical，而非判断数值是否 >100 - 多技能共存时（如闪避+护盾），用Tag组合（
State.Invincible & State.Dashing）比布尔变量更可靠；GAS内置的FGameplayTagContainer支持高效位运算查询 - Tag不自动同步到客户端——若服务端用
AddLooseGameplayTag添加状态，客户端需通过OnGameplayTagAdded委托接收，且Tag必须在GameplayTags.ini中预声明或运行时注册
最易被忽略的一点：GAS技能的“取消”不是可选项，而是必选项。哪怕是最简单的火球术，也得实现 CancelAbility 并清理所有Timer、Delegate、GE Handle——否则玩家连按两次技能，第二次会因第一次残留的Timer或未释放的GE引用而崩溃或错乱。状态管理不是附加功能，它是GAS区别于普通蓝图技能系统的底层契约。
