企业官网建设流程全解析

做 UE5 GAS 的 RPG 项目，绕不开的第一个数值问题就是血量和蓝量怎么随等级涨。你会发现教程里大多只教你用 SetByCaller 塞一个数进去，真到要做“1 级 100 血、50 级 4000 血、每级还带一点曲线加速”的时候，那套写法立刻就不够用了。这篇我就拿手头一个模拟项目里的做法，把 UE5 GAS 中用 MMC（ModMagnitudeCalculation）根据等级计算血量和蓝量上限的第一半讲透——属性该放在哪、MMC 类怎么建、属性捕获怎么注册、计算函数里怎么写才不出错，以及那些文档里不会写但一定会踩的坑。适合已经能跑起一个最小 GAS 环境、写过 AttributeSet 和 GameplayEffect，但还没把“等级驱动数值”这套链路彻底跑通的同学。哪怕你只是刚把 GAS 插件挂上，照着走也能把结构搭起来。

1. 血蓝随等级成长的方案选型

1.1 从一条最朴素的数值需求说起

模拟项目最早的需求单写得很简单：角色升级以后，血量上限和蓝量上限要跟着变，不同职业成长曲线不一样，坦克血厚但涨得慢，法师血薄但蓝涨得快。就这么一句话，落到 GAS 里其实牵出三个独立问题：等级这个数据用什么载体存、上限这个属性由谁去改、改的时候公式从哪来。

很多人第一反应是在 Character 的升级函数里直接算：MaxHealth = 100 + Level * 20，然后调SetNumericAttributeBase。这个写法在单机 Demo 里跑得飞快，两小时就能看到效果。问题是它绕开了 GAS 的聚合器，属性变化不经过 GameplayEffect，所有依赖 GameplayEffect 的机制——比如“装备加成 20% 生命”“诅咒降低最大生命”“临时增益”——都会跟这个直接赋值打架，最后你会看到属性面板的数字和实际生效的数字对不上。

我当时的判断很明确：上限类属性必须走 GameplayEffect 修改，不能裸赋值。因为 GAS 的属性最终值是由 Aggregator 把 BaseValue 和一堆 Modifier 聚合出来的，你手动改 BaseValue 等于在聚合体系外面另开一条路，短期省事，长期全是坑。所以问题就收敛成了：怎么让一个 GameplayEffect 的 Modifier 数值，随时间点和角色等级动态变化。这就是 MMC 要干的事。

1.2 硬编码、SetByCaller、MMC 三条路的差别

在 GAS 里给 Modifier 提供数值，主流有三条路，我按实际使用感受排一下。

SetByCaller 的问题不在技术，在组织。假设你有 8 个职业、每个职业 3 条成长线、还要支持洗点重算，那“谁来算这个数”就变成了全项目最脏的地方。我见过一个项目在 12 个不同文件里都写了100 + Level * 20，后来策划把每级成长从 20 改成 18，改漏了两处，玩家 30 级以后血量凭空多出 60 点，查了两天才定位到。

MMC 的价值在于把“算数值”这件事收进一个类里，数值公式只有一份，输入是 GAS 体系内的属性，输出是 Modifier 的 magnitude。策划改曲线只改资产，代码不用动，这是它最实际的收益。

1.3 MMC 和 ExecutionCalculation 该怎么分工

新手最容易混的就是这两个。两者都能自定义计算，但定位完全不同。

UGameplayModMagnitudeCalculation（MMC）只负责算一个 Modifier 的数值，它返回一个 float，这个 float 会被聚合器按 Modifier 的 Op（Add、Multiply、Override 等）合进属性里。它轻、快、可以缓存，适合“上限随等级”“攻击力随力量”这类纯数值映射。

UGameplayEffectExecutionCalculation（Execution）是一次完整的执行，可以同时读写多个属性、处理护甲减伤、暴击判定、伤害分摊，它跑在 GameplayEffect 的 Execute 阶段，能拿到完整的 Spec 和上下文。伤害结算必须用它，因为要同时读攻击、防御、暴击率并写目标血量。

我的划分标准很粗暴：只输出一个数、不修改其他属性，用 MMC；要读多个属性并写多个属性，用 Execution。血量上限和蓝量上限显然属于前者，所以这篇只谈 MMC，Execution 留到后面单独讲。

2. 属性基座：让等级成为可被捕获的数据

2.1 AttributeSet 里该放哪些字段

MMC 计算的输入来自属性捕获，所以第一步是把“等级”变成一个 GameplayAttribute。这里有个常见分歧：有人觉得等级是角色基础数据，不该塞进 AttributeSet；也有人觉得既然 GAS 要用，就放进去。

我站后者。等级放进 AttributeSet 以后，它能被捕获、能被 GameplayEffect 修改、能参与属性聚合、能随 ASC 一起复制，这条路是最顺的。放在 PlayerState 的普通 UPROPERTY 上也能用，但你得在 MMC 里绕出去拿 Actor，再转成 ASC，再读字段，链路长了，出错点也多了。

属性集的头文件大概是这个样子：

// MyAttributeSet.h #pragma once #include "CoreMinimal.h" #include "AttributeSet.h" #include "AbilitySystemComponent.h" #include "MyAttributeSet.generated.h" #define ATTRIBUTE_ACCESSORS(ClassName, PropertyName) \ GAMEPLAYATTRIBUTE_PROPERTY_GETTER(ClassName, PropertyName) \ GAMEPLAYATTRIBUTE_VALUE_GETTER(PropertyName) \ GAMEPLAYATTRIBUTE_VALUE_SETTER(PropertyName) \ GAMEPLAYATTRIBUTE_VALUE_INITTER(PropertyName) UCLASS() class MYGASRPG_API UMyAttributeSet : public UAttributeSet { GENERATED_BODY() public: UMyAttributeSet(); UPROPERTY(BlueprintReadOnly, Category = "RPG|Base") FGameplayAttributeData Level; ATTRIBUTE_ACCESSORS(UMyAttributeSet, Level); UPROPERTY(BlueprintReadOnly, Category = "RPG|Vital") FGameplayAttributeData MaxHealth; ATTRIBUTE_ACCESSORS(UMyAttributeSet, MaxHealth); UPROPERTY(BlueprintReadOnly, Category = "RPG|Vital") FGameplayAttributeData Health; ATTRIBUTE_ACCESSORS(UMyAttributeSet, Health); UPROPERTY(BlueprintReadOnly, Category = "RPG|Vital") FGameplayAttributeData MaxMana; ATTRIBUTE_ACCESSORS(UMyAttributeSet, MaxMana); UPROPERTY(BlueprintReadOnly, Category = "RPG|Vital") FGameplayAttributeData Mana; ATTRIBUTE_ACCESSORS(UMyAttributeSet, Mana); protected: virtual void PreAttributeChange(const FGameplayAttribute& Attribute, float& NewValue) override; virtual void PostGameplayEffectExecute(const FGameplayEffectModCallbackData& Data) override; };

注意Level用的是FGameplayAttributeData而不是裸 float。这一点别偷懒，裸 float 的属性在 UE5 GAS 里能做捕获但不参与聚合器，很多边界情况会莫名其妙失效。另外ATTRIBUTE_ACCESSORS宏会生成GetLevelAttribute()这种静态函数，MMC 里注册捕获定义靠的就是它。

2.2 等级放在属性上还是放在 Actor 上

我在两个不同规模的项目里都试过，结论要看你的等级会不会被 GameplayEffect 改写。

如果等级是纯粹的“角色成长进度”，只增不减、只有服务器能改，那放属性上完全没问题，还能顺便利用属性的复制机制。但如果你的设计里有“临时降级”“等级压制”“副本内等级同步”这类需求，等级就必须走 GameplayEffect 来改，那更是只能放属性上。

反过来，如果等级还牵涉大量非 GAS 逻辑——比如解锁技能树、开启地图、判定装备需求——放在 PlayerState 上让 Gameplay 层直接读会更方便，MMC 里再通过Spec.GetContext()把 Actor 捞出来读字段。

我最终选了混合方案：AttributeSet 上有一份Level属性作为 GAS 内的“权威副本”，PlayerState 上有一份普通字段作为 Gameplay 层的便捷入口，升级时由升级流程统一写入两边。听起来有冗余，但避免了在 MMC 里到处捞 Actor，也不用担心 MMC 因为拿不到 World 上下文而崩掉。

提示：MMC 的计算函数是 const 的，而且引擎可能在不同的时机调用它，包括在对象还没有完整 World 上下文的时候。所以不要在 MMC 里依赖GetWorld()、不要做GetAllActorsOfClass这类遍历，能不出去就不出去。

2.3 属性初始化与复制的基本约定

属性集的构造函数里建议把默认值都设一遍，哪怕你打算用 GE 覆盖：

UMyAttributeSet::UMyAttributeSet() { InitLevel(1.f); InitMaxHealth(100.f); InitHealth(100.f); InitMaxMana(50.f); InitMana(50.f); }

InitXxx系列函数把值写进 BaseValue，不走聚合器，是初始化阶段的合理手段。这么做的意义在于：即使后续 GE 应用失败、配置写错、或者某个角色忘了挂初始化流程，属性也不会是 0，不会出现“一进游戏就死”这种低级事故。

复制方面，属性复制走GetLifetimeReplicatedProps，把需要同步的属性加进去。这里有个经验：Level一定要复制，因为客户端要靠它算 UI 显示的血量上限；Health、Mana这类当前值必须复制；MaxHealth、MaxMana这类派生值其实可以不复制——客户端本地用同一个 MMC 算一遍就行，省带宽。但如果你的 MMC 依赖了客户端拿不到的数据（比如服务器专属的配置表），那就老老实实复制。

还有一个前置条件容易被漏：UAbilitySystemGlobals::Get().InitGlobalData()必须在 GameInstance 初始化阶段调一次。不调的话，CapturedSourceTags、CapturedTargetTags这些聚合标签会出问题，严重的时候直接崩。这是 GAS 新手最常见的第一个拦路虎，跟 MMC 本身无关，但会让你误以为是 MMC 写错了。

3. 创建 MMC 类并完成属性捕获

3.1 类声明与文件组织

MMC 是一个 UObject 子类，继承UModMagnitudeCalculation。头文件在GameplayModMagnitudeCalculation.h，命名上我习惯加MMC_前缀，跟GE_、GA_、GC_形成统一风格，找起来快。

// MMC_MaxHealthByLevel.h #pragma once #include "CoreMinimal.h" #include "GameplayModMagnitudeCalculation.h" #include "CurveFloat.h" #include "MMC_MaxHealthByLevel.generated.h" UCLASS() class MYGASRPG_API UMMC_MaxHealthByLevel : public UModMagnitudeCalculation { GENERATED_BODY() public: UMMC_MaxHealthByLevel(); // 曲线资产在类默认值里指定，GE 实例化 MMC 时读的是 CDO 上的值 UPROPERTY(EditDefaultsOnly, Category = "RPG|Curve") TObjectPtr<UCurveFloat> HealthByLevelCurve = nullptr; protected: virtual float CalculateBaseMagnitude_Implementation(const FGameplayEffectSpec& Spec) const override; private: FGameplayEffectAttributeCaptureDefinition LevelCaptureDef; };

这里我故意把曲线做成EditDefaultsOnly的 UPROPERTY，后面会讲它为什么只能配在类默认值上，以及在 GE 上换曲线该怎么做。类里不要放任何运行时状态——计数器、缓存数组、上次计算结果，全都不行。理由在 3.3 节展开。

3.2 构造函数里注册捕获定义

属性捕获必须在构造函数里完成，这是硬性要求。RelevantAttributesToCapture这个数组在对象构造时就确定了，运行时往里加不会生效，因为聚合器在应用 GE 之前就已经根据这个列表准备好了捕获信息。

UMMC_MaxHealthByLevel::UMMC_MaxHealthByLevel() { LevelCaptureDef = FGameplayEffectAttributeCaptureDefinition( UMyAttributeSet::GetLevelAttribute(), EGameplayEffectAttributeCaptureSource::Target, false); RelevantAttributesToCapture.Add(LevelCaptureDef); }

拆开看这三个参数。

第一个是属性本身，用UMyAttributeSet::GetLevelAttribute()拿到FGameplayAttribute，这个静态函数由ATTRIBUTE_ACCESSORS宏生成。

第二个是捕获源，Source还是Target。这里必须想清楚 GE 是“谁对谁施加”。血量上限这种 GE，通常是角色给自己施加（Self），或者升级系统对角色施加，Source 和 Target 都是同一个 ASC。但如果你的设计里有“Buff 提供者给目标加生命上限”，那 Source 和 Target 就不同了，捕获源写错的话拿到的永远是 0。

判断方法很简单：问自己“这个数值由谁决定”。血量上限由被施加者自己的等级决定，所以捕获 Target。如果有个“队长光环给队友加 10% 生命”，那 10% 的基准来自施加者的某个属性，就该捕获 Source。

第三个参数是bSnapshot，下面单独说。

3.3 Snapshot 开关会带来什么差异

bSnapshot = true表示在 GE 被应用的那一瞬间，把捕获属性的当前值“拍照”存下来，之后无论这个属性怎么变，MMC 用的都是快照值。false表示每次都实时去读当前值。

这个开关直接影响升级后的表现。血量上限 GE 如果是快照模式，角色从 10 级升到 11 级，等级属性变了，但 GE 里用的还是 10 级时的快照，血量上限不会变，你得手动把 GE 移除再重新应用。

我把血量上限的捕获设为false，走实时读取，这样等级一变，理论上聚合器重新评估时就会用新值。但实测下来不能完全指望隐式重算：属性聚合的触发时机跟 GE 的堆叠、标签、执行阶段都有关，某些情况下你改了Level，界面上限确实变了，但当前Health没有跟着钳制，会出现“血量 120/100”这种越界显示。稳妥做法是升级流程里显式触发一次刷新，具体怎么做放到下篇讲，上篇先把计算本身做对。

注意：bSnapshot不是性能开关。它的语义是“取值时机”，不是“优化选项”。选错了会直接导致逻辑不符合预期，比性能问题严重得多。

还有一条容易被忽略：MMC 实例是“无状态”的。引擎在计算 Modifier 数值时会实例化计算类，某些版本里还会做缓存复用，所以你绝对不能在里面写static变量或者用成员变量做累加。我见过有人在 MMC 里写static int32 CallCount调试，上线前忘了删，结果多线程下数值直接错乱。要调试就老老实实打 Log，别留状态。

4. 计算函数内部：从捕获值到最终数值

4.1 取值、判空与失败兜底

CalculateBaseMagnitude_Implementation是唯一需要重写的函数。它接收FGameplayEffectSpec，返回一个 float，这个 float 就是这个 Modifier 的 BaseMagnitude。

float UMMC_MaxHealthByLevel::CalculateBaseMagnitude_Implementation(const FGameplayEffectSpec& Spec) const { FAggregatorEvaluateParameters EvalParams; EvalParams.SourceTags = Spec.CapturedSourceTags.GetAggregatedTags(); EvalParams.TargetTags = Spec.CapturedTargetTags.GetAggregatedTags(); float Level = 0.f; if (!GetCapturedAttributeMagnitude(LevelCaptureDef, Spec, EvalParams, Level)) { UE_LOG(LogTemp, Warning, TEXT("[MMC_MaxHealthByLevel] 等级捕获失败 %s"), *Spec.ToDebugString()); return 100.f; // 兜底值，绝不要返回 0 } // 后续计算... }

FAggregatorEvaluateParameters里那两个标签很关键。它们决定了属性聚合时哪些 Modifier 会被计入——如果目标身上有“降低等级”的 Debuff，它的 Modifier 只有在标签匹配时才会被聚合进来。不填这两个标签，捕获到的是纯 BaseValue，所有增益减益全部失效，你会在调试时非常困惑：面板上明明显示等级被减了，MMC 算出来却没变。

失败兜底返回 100 而不是 0，这是血泪教训。返回 0 意味着最大生命为 0，角色立刻死亡，而且这个状态会被复制到客户端，看起来就像“进游戏秒死”。给一个合理的兜底值，配合 Warning 日志，至少能让你在日志里看到问题，而不是对着一个秒死的角色猜半天。

4.2 分级成长的三种写法：线性、分段、曲线查表

拿到等级以后，怎么映射到血量，有三种常见写法，按项目规模选。

线性公式最简单，Base + (Level - 1) * PerLevel。100 基础血、每级 20，50 级就是 1080。优点是心算方便、策划容易理解、不需要任何资产。缺点是成长感很平，后期玩家会觉得“升级没感觉”。

分段公式是在线性基础上加拐点，比如 1 到 20 级每级 +20，21 到 40 级每级 +35，41 级以后每级 +50。写法是一堆 if-else，或者用数组配阈值。代码丑但可控，适合数值策划不确定最终曲线、需要频繁手调的阶段。

曲线查表是最终形态，用UCurveFloat或UCurveTable把等级到血量的映射做成资产，策划在编辑器里拉曲线，代码只负责Curve->GetFloatValue(Level)。改数值不用重新编译，不用提交代码，这是它最大的价值。

我现在的写法是三层兜底：优先查曲线资产，曲线没配或者查出来是 0 就走分段常量，分段也没配就走线性。这样即使策划把曲线资产删了，游戏也不会崩。

const int32 LevelInt = FMath::Clamp(FMath::FloorToInt(Level), 1, 200); if (HealthByLevelCurve) { const float CurveValue = HealthByLevelCurve->GetFloatValue(static_cast<float>(LevelInt)); if (CurveValue > KINDA_SMALL_NUMBER) { return static_cast<float>(FMath::RoundToInt(CurveValue)); } } // 兜底：线性成长 constexpr float BaseHealth = 100.f; constexpr float PerLevel = 20.f; return static_cast<float>(FMath::RoundToInt(BaseHealth + PerLevel * (LevelInt - 1)));

蓝量的 MMC 结构完全一样，只是曲线资产和兜底参数不同。我一开始想着“能不能一个 MMC 同时算血和蓝”，答案是不行——MMC 一次只输出一个数值，血和蓝必须是两个 Modifier，那就得是两个 MMC 类，或者同一个类配两套默认值（做不到，因为类只有一个 CDO）。所以老老实实建两个类，公共逻辑抽成静态工具函数。

4.3 钳制、取整与浮点误差

三个细节必须处理。

第一是等级钳制。属性是 float 的，聚合器算完可能是 10.9999 或者 -3，直接拿去查曲线会读到奇怪的区间。我在进函数第一件事就是FloorToInt再Clamp，最小值 1，最大值按项目等级上限定（我这里是 200）。这个上限不要省，曲线资产的横轴如果只画到 100 级，你读到 150 级时GetFloatValue会返回最后一个关键帧的值，看起来“没崩”但数值是错的。

第二是取整。属性值是 float，但玩家看到的血量是整数。如果你在 MMC 里不取整，MaxHealth可能是 1234.5678，UI 显示 1234，实际判定用 1234.5678，玩家会看到“血量显示 1 但还没死”这种诡异现象。RoundToInt之后转回 float 是我习惯的做法。

第三是浮点比较。判断曲线返回值是否有效，不要写if (CurveValue > 0.f)，用KINDA_SMALL_NUMBER（约 1e-4）。曲线在低等级段可能算出 0.0001 这种值，> 0判定为真，但你实际上想要的是走兜底逻辑。

提示：如果你在PreAttributeChange里对MaxHealth做了额外钳制，注意 MMC 返回的是 BaseMagnitude，它还要经过 Op（Add、Multiply、Override）和后续 Modifier 聚合，最终值不一定等于你返回的值。排查问题时要在PostGameplayEffectExecute里打日志看最终值，而不是只看 MMC 的返回值。

5. 把 MMC 挂到 GameplayEffect 上

5.1 Modifier 的配置细节

GE 资产里，找到 Modifiers 数组，加一条。Attribute 选MyAttributeSet.MaxHealth，Modifier Op 我选Override，Magnitude Calculation Type 选Custom Calculation Class，然后在Calculation Class里填MMC_MaxHealthByLevel。

为什么用Override而不是Add？因为语义是“设定上限”，不是“在上限基础上加”。用Add的话，每次升级重新应用 GE 都会再叠一份，10 级时上限变成 100+120+140+160…，指数级膨胀。用Override则每次都把 BaseValue 直接设成计算结果，天然幂等，重复应用多少次结果都一样。

这个 Op 的选择直接决定了你的升级流程要不要写“先移除旧 GE”的逻辑。用Override就不需要，用Add就必须移除旧的，否则必然叠爆。我在早期版本里用过Add，升级十次以后血量上限六位数，排查了半天才发现是 GE 叠加。

蓝量 GE 同理，复制一份，Attribute 换成MaxMana，Calculation Class 换成MMC_MaxManaByLevel。

5.2 初始化 GE 与升级 GE 的分离

这里有个顺序问题必须讲清楚：MMC 依赖Level属性，所以Level必须先写好，再应用血量上限 GE。如果你在同一个帧里先应用血量 GE 再设置等级，MMC 捕获到的是旧等级甚至 0。

我把它拆成两个 GE 资产：GE_SetLevel负责写等级，用 SetByCaller 传值；GE_InitMaxVitals负责算血蓝上限。应用流程大概是这样：

void UMyLevelComponent::ApplyLevelAndRefreshVitals(int32 NewLevel) { UAbilitySystemComponent* ASC = GetOwnerASC(); if (!ASC) { return; } FGameplayEffectContextHandle Ctx = ASC->MakeEffectContext(); Ctx.AddSourceObject(GetOwner()); // 第一步：先写等级 FGameplayEffectSpecHandle LevelSpec = ASC->MakeOutgoingSpec(GE_SetLevel, 1.f, Ctx); if (LevelSpec.IsValid()) { LevelSpec.Data->SetSetByCallerMagnitude(TAG_Data_Level, static_cast<float>(NewLevel)); ASC->ApplyGameplayEffectSpecToSelf(*LevelSpec.Data.Get()); } // 第二步：再算上限 FGameplayEffectSpecHandle VitalSpec = ASC->MakeOutgoingSpec(GE_InitMaxVitals, 1.f, Ctx); if (VitalSpec.IsValid()) { ASC->ApplyGameplayEffectSpecToSelf(*VitalSpec.Data.Get()); } // 第三步：把当前值填到新上限 const float NewMaxHealth = ASC->GetNumericAttribute(UMyAttributeSet::GetMaxHealthAttribute()); ASC->SetNumericAttributeBase(UMyAttributeSet::GetHealthAttribute(), NewMaxHealth); const float NewMaxMana = ASC->GetNumericAttribute(UMyAttributeSet::GetMaxManaAttribute()); ASC->SetNumericAttributeBase(UMyAttributeSet::GetManaAttribute(), NewMaxMana); }

第三步容易被忽略。上限变成 200 了，当前血还是 100，玩家升级后血条不满，体验很怪。有人会想“在 GE 里再加一条 Modifier 把 Health 也设成 MaxHealth”，但同一个 GE 内多个 Modifier 的执行顺序不保证，你没法确保 Health 的 Modifier 在 MaxHealth 之后执行。分两步，先用 GE 改上限，再在代码里读上限回填当前值，顺序完全可控。

5.3 一个容易忽略的点：MMC 的类默认值

GE 里的Calculation Class填的是TSubclassOf<UGameplayModMagnitudeCalculation>，引擎在运行时按这个类去实例化一个对象来算数值。关键点是：它实例化时不会给你一个可配置的实例，用的是类默认对象（CDO）上的属性值。

这意味着你在 MMC 类里写的HealthByLevelCurve，只能在类默认值里配一次，所有用这个 MMC 的 GE 共享同一份。如果你想让“战士血量 GE”和“法师血量 GE”用不同曲线，不能靠同一个 MMC 类配不同资产，只能建两个 MMC 子类，各自配各自的曲线。

UCLASS() class MYGASRPG_API UMMC_MaxHealthByLevel_Warrior : public UMMC_MaxHealthByLevel { GENERATED_BODY() public: UMMC_MaxHealthByLevel_Warrior(); }; UMMC_MaxHealthByLevel_Warrior::UMMC_MaxHealthByLevel_Warrior() { static ConstructorHelpers::FObjectFinder<UCurveFloat> CurveFinder( TEXT("/Game/RPG/Curves/CF_WarriorHealth.CF_WarriorHealth")); if (CurveFinder.Succeeded()) { HealthByLevelCurve = CurveFinder.Object; } }

用ConstructorHelpers::FObjectFinder有个前提：资产路径必须固定且已存在，路径写错不会崩但曲线为空，会静默走兜底逻辑。上线前一定要在 PIE 里断点看一眼HealthByLevelCurve是不是空的。我吃过这个亏，美术重命名了曲线资产，代码里路径失效，所有人血量都变成线性兜底值，还以为是数值策划改了表。

另一个更灵活的方案是把曲线放到UCurveTable里，MMC 里通过UAbilitySystemGlobals或者一个配置类的软引用来拿表，再按行名查。这样一份表管所有职业，新增职业不用加代码。缺点是查表时要处理行名拼写、表加载时机，复杂度高一些。项目职业数量少于 5 个的时候，我建议就用子类方案，简单直接。

6. 常见故障与排查清单

6.1 数值不生效的六个高频原因

MMC 写完挂上去，第一次跑大概率是不生效的。我把踩过的坑整理成表，按排查优先级排。

这六条能覆盖我遇到的九成问题。剩下的一成通常更隐蔽，比如属性集没有正确注册到 ASC（GetSet返回空）、ASC 挂在了错误的 Actor 上、或者 GE 的Duration Policy配成了Instant导致效果应用完立刻消失。

6.2 数值跳变与重复叠加

有一种很难查的现象：角色升级时血量上限会短暂跳到正确值，然后立刻掉回去。这通常是因为有两处逻辑在同时改MaxHealth——一处是升级流程里的 Override GE，另一处是某个初始化 GE 或存档恢复流程。

排查方法是在PostGameplayEffectExecute里对MaxHealth打日志，把每次修改的来源、旧值、新值都打出来。日志里如果看到同一个帧内出现两次修改，就能定位到是谁在抢。

另一种情况是MaxHealth被正确设置了，但Health没有跟着钳制，出现“150/100”。这个必须在PreAttributeChange里处理：

void UMyAttributeSet::PreAttributeChange(const FGameplayAttribute& Attribute, float& NewValue) { Super::PreAttributeChange(Attribute, NewValue); if (Attribute == GetHealthAttribute()) { NewValue = FMath::Clamp(NewValue, 0.f, GetMaxHealth()); } else if (Attribute == GetManaAttribute()) { NewValue = FMath::Clamp(NewValue, 0.f, GetMaxMana()); } }

注意PreAttributeChange只在 CurrentValue 变化时触发，不处理 BaseValue 的直接修改。所以SetNumericAttributeBase那条路它是拦不住的，得靠PostGameplayEffectExecute再兜一次。

6.3 多人环境与调试手段

如果在做联机，MMC 相关的问题会翻倍。核心原则只有一条：影响实际数值的计算只在服务器执行，客户端只做预测和显示。

GE 应用走ApplyGameplayEffectSpecToSelf在服务器执行，属性复制到客户端。客户端本地也会跑一遍 MMC（因为属性聚合是双向的），如果客户端缺数据——比如曲线资产没加载——就会算出不一样的数，表现为“客户端看到 1000 血，服务器认为 800 血”。

调试手段上，我常用的有三个。一是控制台showdebug abilitysystem，能看到当前 ASC 上所有属性、所有激活的 GE、以及每个属性的聚合来源。二是AbilitySystem.Debug.NextCategory之类的调试命令配合日志分类。三是在 MMC 里临时加UE_LOG打出等级、曲线值、返回值，跑一次 PIE 就知道链路哪一段断了。

最后一个经验：MMC 的调试日志一定要带上前缀和 Spec 的调试字符串（Spec.ToDebugString()），多人测试时日志会刷得飞快，没有前缀你根本分不清是哪个角色的计算。

我在模拟项目里把血量和蓝量的 MMC 跑通以后，最大的感受是：这套结构一旦搭对，后面加护甲、加法强、加暴击伤害，全都是一模一样的套路，只是换个属性、换个曲线。真正麻烦的不是计算本身，而是“谁在什么时候触发重算”这个时序问题——升级后上限什么时机刷新、刷新时当前值怎么处理、联机时客户端的预测怎么对齐，这些才是下篇要啃的硬骨头。曲线资产怎么组织、多个 MMC 怎么共用配置、升级瞬间的刷新流程和动画衔接，我会在下一篇里连同完整的升级链路一起拆开讲。如果你现在卡在“数值不生效”，先按 6.1 那张表从下往上查，八成能在十分钟内定位到问题。