UE5 C++开发避坑指南：USTRUCT、UENUM与ExposeOnSpawn的正确使用

1. 项目概述：为什么UE5 C++中的数据结构定义是个“坑”？

在虚幻引擎5（UE5）的C++开发中，USTRUCT和UENUM是构建游戏数据模型的基石。它们看起来简单——无非是给结构体和枚举加上一个宏前缀，但实际用起来，新手甚至是有经验的开发者都容易掉进一系列“坑”里。这些错误轻则导致编辑器中的属性面板不显示、蓝图无法正常使用，重则引发难以追踪的运行时崩溃或序列化数据丢失。更别提那个听起来很酷的ExposeOnSpawn属性，用错了地方，你的Actor构造逻辑就会变得一团糟。

我自己在项目里就踩过不少这样的坑。比如，曾经花了大半天时间调试一个USTRUCT变量，它在C++里赋值一切正常，但一到蓝图中就永远是默认值。最后发现，仅仅是因为少写了一个关键的宏参数。还有一次，试图在Actor的构造函数里使用一个标记了ExposeOnSpawn的变量，结果发现它根本还没被初始化。这些经历让我意识到，UE的反射系统（Reflection System）虽然强大，但规则也很严格，必须“按规矩办事”。

这篇文章，就是一份来自一线的“避坑指南”。我不会重复官方文档里那些基础定义，而是聚焦于那些文档里语焉不详、社区里反复提问、以及我亲身踩过的“雷区”。我们会深入探讨USTRUCT和UENUM在声明、使用、序列化以及与蓝图交互时最常见的错误，并提供经过验证的解决方案。特别是ExposeOnSpawn这个技巧，我会详细解释它的工作原理、适用场景以及那些绝对不能踩的“禁区”。无论你是刚接触UE5 C++的开发者，还是想巩固底层知识的老手，这份指南都能帮你节省大量调试时间，写出更健壮、更易维护的代码。

2. USTRUCT 的深度解析与常见陷阱

USTRUCT允许我们创建在蓝图中可访问、可编辑、可被UE属性系统（如序列化、复制、细节面板显示）识别的自定义数据结构。它比普通的C++结构体强大得多，但约束也随之而来。

2.1 声明与基础属性：不止是加个宏那么简单

最常见的错误始于声明本身。很多人以为只要在结构体前加上USTRUCT()就万事大吉。

// 错误示例1：缺少必要的宏参数 USTRUCT() struct FMyData { int32 Value; FString Name; };

这个结构体虽然能编译，但它在蓝图中几乎不可用。Value和Name不会出现在属性面板，也无法被蓝图节点访问。因为它缺少了让成员变量暴露给反射系统的关键宏：GENERATED_BODY()和UPROPERTY()。

正确的声明应该是：

// 正确示例 USTRUCT(BlueprintType) // BlueprintType 允许此结构体作为变量类型在蓝图中使用 struct FMyData { GENERATED_BODY() // 必须！用于生成反射代码体。 // 希望暴露给蓝图的成员变量，必须使用UPROPERTY宏 UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = “MyData”) int32 Value = 0; UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = “MyData”) FString Name; // 构造函数（非必需，但推荐用于初始化） FMyData() : Value(0) {} };

关键点解析：

1. GENERATED_BODY()：这个宏必须放在结构体内部的最开始。它会被预处理器展开，包含一系列类型描述符和函数声明，是UE反射系统的入场券。没有它，这个USTRUCT就是个“哑巴”。
2. UPROPERTY()：这是赋予成员变量“超能力”的宏。没有它，变量只是一个普通的C++成员，无法被编辑器序列化、无法在蓝图中读写、也无法被网络复制。
   • EditAnywhere: 允许在属性面板（如Actor的Details面板、蓝图的变量列表）中编辑。
   • BlueprintReadWrite: 允许蓝图既读取也写入该变量。
   • Category: 在属性面板中将变量分组，保持整洁。
3. BlueprintType：在USTRUCT()宏内指定这个元数据（Meta Specifier），是允许该结构体类型出现在蓝图变量下拉列表中的前提。如果你希望能在蓝图中声明一个FMyData类型的变量，就必须加上它。
4. 默认构造函数：UE的反射系统和容器（如TArray<FMyData>）经常需要默认构造对象。提供一个默认构造函数（或确保所有成员都有默认值）可以避免未初始化内存带来的问题。虽然现代C++/UE的某些情况下可能不需要显式声明，但显式声明是一个好习惯，尤其是当你有非平凡成员时。

实操心得：我习惯为每一个USTRUCT都立即写上GENERATED_BODY()和BlueprintType。对于成员变量，即使暂时不想暴露给蓝图，如果它需要被序列化（保存到磁盘）或复制，也先加上UPROPERTY()并设置合适的权限（如SaveGame或Replicated）。这比事后发现数据丢失再加要省事得多。

2.2 序列化与默认值：数据为何“不翼而飞”？

序列化是UE保存和加载游戏状态的核心机制。USTRUCT的序列化行为与普通结构体不同，理解不当会导致存档读档时数据错误。

陷阱1：非UPROPERTY成员不序列化只有标记了UPROPERTY()的变量才会被自动序列化。这意味着你在运行时通过计算赋值的非UPROPERTY成员，在游戏存档后重新加载时，其值会丢失，变回默认值或未初始化状态。

USTRUCT() struct FPlayerState { GENERATED_BODY() UPROPERTY(SaveGame) // 正确：会被保存 int32 SavedScore = 0; int32 TemporaryBonus = 0; // 危险！没有UPROPERTY，序列化时被忽略 // 假设在游戏中 TemporaryBonus = 100; // 存档再读档后，TemporaryBonus 会变回 0，而 SavedScore 仍是 100。 };

解决方案：仔细评估每个成员的生命周期。需要持久化的数据，务必加上UPROPERTY(SaveGame)。临时计算用的中间变量，可以不加，但要清楚其数据不会保留。

陷阱2：动态内存指针的序列化如果USTRUCT包含裸指针（T*）或TSharedPtr指向动态分配的内存，默认的序列化可能无法正确处理深拷贝，容易造成内存泄漏或悬挂指针。

USTRUCT() struct FComplexData { GENERATED_BODY() UPROPERTY() TArray<int32>* DynamicArrayPtr = nullptr; // 危险！指针序列化的是地址值，不是内容。 };

解决方案：

1. 优先使用值类型：对于USTRUCT，尽量使用TArray、TMap、FString等UE提供的、自带序列化支持的值类型容器。

   UPROPERTY() TArray<int32> DynamicArray; // 安全，TArray自己知道如何序列化。

2. 使用UPROPERTY()包装智能指针：如果必须用指针，使用UObject派生类的指针，并用UPROPERTY()修饰，UE会处理引用和序列化。

   UPROPERTY() class UMyObject* MyObjectPtr = nullptr; // 指向UObject，可以序列化

3. 自定义序列化：对于极其复杂的自定义数据，可以重写FMyStruct::Serialize(FArchive& Ar)函数，但这是高级话题，需谨慎处理。

陷阱3：默认值设置时机不当你可能会在结构体的构造函数里设置默认值，但要注意，当这个结构体作为UPROPERTY在编辑器中有一个默认值时，构造函数的赋值可能不会覆盖编辑器中设置的值。引擎在加载资产或默认对象时，会应用在编辑器中配置的值。

USTRUCT() struct FConfig { GENERATED_BODY() UPROPERTY(EditAnywhere, Category = “Config”) float Speed = 150.0f; // 这是推荐的设置默认值的方式 FConfig() { // 如果编辑器中把Speed改成了200，这个赋值会被覆盖。 // Speed = 150.0f; // 不如直接在UPROPERTY行设置直观和可靠。 } };

最佳实践：直接在UPROPERTY声明处使用= value语法设置默认值。这既是代码中的默认值，也是编辑器中的初始值，两者统一，避免混淆。

2.3 在容器中的使用：TArray 的隐秘角落

将USTRUCT放入TArray、TSet或TMap中使用非常普遍，但这里也有坑。

陷阱：结构体内含UObject引用时的容器操作如果USTRUCT包含UPROPERTY()修饰的UObject*指针，在对容器进行整体赋值、移动或Memcpy等操作时，需要特别小心。UE的垃圾回收（GC）系统跟踪这些引用，不恰当的内存操作可能导致GC无法正确更新引用，引发崩溃。

USTRUCT() struct FAttachmentInfo { GENERATED_BODY() UPROPERTY() class USceneComponent* AttachedTo = nullptr; // GC跟踪的引用 }; TArray<FAttachmentInfo> OriginalArray; // ... 填充数据 ... TArray<FAttachmentInfo> CopiedArray = OriginalArray; // 值拷贝，通常没问题，GC引用会被正确复制。 // 但是，如果使用 FMemory::Memcpy 来拷贝整个数组内存，就可能出问题！

解决方案：

1. 避免对包含UObject引用的USTRUCT进行原始内存操作。坚持使用容器自带的方法（=赋值、Add、Append等），这些操作会确保对象引用的正确处理。
2. 如果需要进行高性能批量操作，务必深入了解UE的TTypeTraits和TIsTriviallyCopyable，但这属于高级优化范畴，绝大多数情况不需要。

另一个常见问题：TArray<FMyStruct>在蓝图中的暴露如果你想在蓝图中编辑一个结构体数组，需要确保：

1. 结构体本身有BlueprintType。
2. 数组属性本身也被正确标记。

   UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = “Inventory”) TArray<FItemData> InventoryItems; // FItemData 必须是 BlueprintType 的 USTRUCT

   这样，在蓝图的细节面板中，你就可以展开这个数组，并编辑其中每一个FItemData元素的属性了。

3. UENUM 的声明、扩展与蓝图交互难题

UENUM用于创建在蓝图中可用的枚举类型。它比USTRUCT简单，但细节决定成败。

3.1 基础声明与元数据：让枚举更“好用”

一个最基本的UENUM声明如下：

UENUM(BlueprintType) // 同样，需要BlueprintType才能在蓝图中作为变量类型使用 enum class ECharacterState : uint8 // 建议使用 enum class 并指定底层类型 { Idle UMETA(DisplayName = “闲置”), Walking UMETA(DisplayName = “行走”), Running UMETA(DisplayName = “奔跑”), Dead UMETA(DisplayName = “死亡”), };

• enum class: 使用强类型枚举（C++11），避免命名污染，更安全。
• : uint8：指定底层类型为uint8，这有助于节省内存（特别是在网络复制时），并且是UE反射系统推荐的做法。
• UMETA(DisplayName = “...”)：这是元数据（Metadata）。它不会影响枚举值本身，但会改变其在编辑器中的显示名称。在蓝图的节点引脚或下拉菜单中，你会看到“闲置”而不是“Idle”，这对设计师和非程序员更友好。

常见错误1：忘记BlueprintType没有BlueprintType，枚举可以在C++中使用，但无法在蓝图的“变量类型”列表中找到，也无法作为函数的蓝图可调用参数或返回类型。

常见错误2：枚举值变化导致的数据不兼容你已经发布了一个版本，枚举定义为：

UENUM() enum class EWeaponType { Sword, Bow, Staff };

游戏存档中保存了EWeaponType::Bow（内部值为1）。后来你更新版本，在中间插入了一个新类型：

UENUM() enum class EWeaponType { Sword, Dagger, Bow, Staff }; // 插入了Dagger

此时，旧存档中值为1的枚举，加载到新游戏里会被解释为EWeaponType::Dagger，而不是Bow，导致逻辑错误甚至崩溃。

解决方案：

• 绝对不要在已使用的枚举序列中间插入新值。新的枚举值应该始终添加在末尾。
• 如果必须插入，需要编写自定义的序列化转换代码，这非常复杂且容易出错。最好的办法就是通过严格的命名和规划来避免。

3.2 枚举类的蓝图暴露与C++交互

在C++中，你可以轻松地将UENUM用作函数参数。

UFUNCTION(BlueprintCallable) void SetState(ECharacterState NewState);

在蓝图中，这个函数会有一个类型为ECharacterState的输入引脚，点击会出现一个漂亮的下拉菜单。

陷阱：枚举的“位标志”（Bitmask）用法有时我们希望一个变量能同时表示多个状态，比如角色同时处于“跳跃”和“无敌”状态。C++中常用位运算（|）来实现。UE也支持，但需要特殊声明。

// 错误：普通枚举无法直接在蓝图中进行位运算 UENUM(BlueprintType) enum class EStatusFlags { None = 0, IsJumping = 1, IsInvincible = 2, IsBurning = 4, }; // 在C++中：Flags |= EStatusFlags::IsJumping | EStatusFlags::IsInvincible; // 在蓝图中：没有直接的“位或”节点可用。

为了让其在蓝图中也能作为标志位使用，需要使用BlueprintType的变体Meta和Bitflags属性（注意：语法随版本略有变化，以下是常见且稳定的一种）：

UENUM(BlueprintType, Meta = (Bitflags, UseEnumValuesAsMaskValuesInEditor = “true”)) // UE5中常见的声明方式 enum class EStatusFlags : uint8 { None = 0 UMETA(Hidden), // 通常隐藏None IsJumping = 1 << 0, IsInvincible = 1 << 1, IsBurning = 1 << 2, }; ENUM_CLASS_FLAGS(EStatusFlags) // 这个宏会为枚举生成 `operator|`, `operator&` 等 UPROPERTY(EditAnywhere, BlueprintReadWrite, Meta = (Bitmask, BitmaskEnum = “EStatusFlags”)) uint8 ActiveStatusFlags; // 注意，这里用 uint8 存储位标志

• Meta = (Bitflags, ...)：告诉编辑器此枚举用于位标志。
• ENUM_CLASS_FLAGS：一个方便的宏，为enum class定义位操作符。
• Meta = (Bitmask, BitmaskEnum = “EStatusFlags”)：在UPROPERTY上使用，告诉编辑器这个uint8变量应该用EStatusFlags的复选框形式在属性面板中显示。

这样，在蓝图的属性面板中，ActiveStatusFlags会显示为一组复选框（IsJumping, IsInvincible, IsBurning），而不是一个下拉菜单。在蓝图脚本中，也有专门的“位操作”节点（如“Has Flag”）来检查状态。

注意事项：使用位标志枚举时，存储变量通常使用与枚举底层类型相同的整数类型（如uint8）。在C++中操作时，使用ENUM_CLASS_FLAGS生成的运算符；在蓝图中，使用“Make Bitmask”或“Has Flag”等节点。确保团队都理解这种用法，避免混淆。

3.3 枚举的迭代与字符串转换

有时我们需要遍历一个枚举的所有值，或者将枚举值转换成可读的字符串（用于UI显示或日志）。

C++中遍历枚举值UE没有内置的运行时遍历UENUM所有值的方法，因为枚举信息主要在编译时和编辑时。但我们可以通过一个技巧来实现，前提是枚举值是连续的：

for (int32 i = 0; i <= (int32)ECharacterState::Dead; ++i) { ECharacterState State = (ECharacterState)i; // 使用State... }

注意：这种方法非常脆弱！一旦枚举值不连续（比如你手动指定了跳跃的值），就会出错。更健壮的方法是维护一个静态数组，但这增加了维护成本。通常，游戏逻辑应避免依赖遍历所有枚举值。

枚举值转字符串（用于显示）这是更常见的需求。UE提供了StaticEnum和GetNameStringByValue。

// 获取枚举对象的静态实例 UEnum* EnumPtr = FindObject<UEnum>(ANY_PACKAGE, TEXT(“ECharacterState”), true); if (EnumPtr) { // 将枚举值转换为显示名称（即UMETA(DisplayName)指定的名字） FString StateName = EnumPtr->GetNameStringByValue((int64)ECharacterState::Running); // StateName 会是 “奔跑” // 如果你想获取原枚举名（“Running”），可以用 EnumPtr->GetNameStringByIndex(...) }

在蓝图中，有现成的“Enum to String”和“Get Display Name”节点，用起来更方便。

4. ExposeOnSpawn 的机制、应用与致命陷阱

ExposeOnSpawn是UPROPERTY的一个元数据标识符，它可能是最容易被误解和误用的特性之一。它的字面意思是“在生成时暴露”，但具体行为需要深刻理解。

4.1 工作原理：它到底在何时“暴露”？

当一个UPROPERTY被标记为ExposeOnSpawn时，它会产生两个关键影响：

1. 在生成（Spawn）的上下文菜单中：当你使用Spawn Actor from Class或Construct Object from Class等蓝图节点时，该属性会作为一个输入引脚出现，允许你在生成对象的那一刻直接设置其初始值。
2. 在构造过程中：这个通过引脚传入的值，会在对象构造函数调用之后、OnConstruction事件（对于Actor）或PostInitProperties调用之前，被设置到属性上。

这是理解所有陷阱的核心：ExposeOnSpawn的属性值，不是在构造函数中可用的。

UCLASS() class AMyActor : public AActor { GENERATED_BODY() public: AMyActor() { // 陷阱！ExposedVariable 在这里还是默认值（0） // 通过 ExposeOnSpawn 设置的值还未生效！ PrimaryActorTick.bCanEverTick = true; // 如果你在这里用 ExposedVariable 去初始化其他组件，会得到错误的值。 } UPROPERTY(EditAnywhere, BlueprintReadOnly, Meta = (ExposeOnSpawn=true)) int32 ExposedVariable = 0; // 默认值 virtual void OnConstruction(const FTransform& Transform) override { Super::OnConstruction(Transform); // 正确！在这里，ExposedVariable 已经被设置为生成时传入的值。 // 可以在这里基于 ExposedVariable 进行初始化逻辑。 } };

4.2 正确使用场景：何时该用 ExposeOnSpawn？

它最适合用于那些在对象生命初期就需要确定，且之后很少改变的配置型参数。

典型场景示例：

1. 武器生成：生成一个子弹Actor时，传入伤害值、发射速度、所属队伍。

   UPROPERTY(BlueprintReadOnly, Meta=(ExposeOnSpawn=true)) float BaseDamage;

2. 特效生成：生成一个粒子特效Actor时，传入颜色、大小、持续时间。
3. 游戏道具生成：生成一个宝箱时，传入里面包含的物品等级或类型。

在这些场景下，参数在生成时确定，之后基本不变，且对象的初始化（如子弹的运动组件设置、特效的颜色初始化）可以安全地放在OnConstruction或BeginPlay中。

4.3 致命陷阱与避坑指南

陷阱一：在构造函数中使用 ExposeOnSpawn 变量这是最经典的错误，如前所述，构造函数中该变量仍是默认值。任何依赖于此变量的组件创建、资源加载都会基于错误的值。

解决方案：将初始化逻辑移至OnConstruction（对于Actor）或PostInitProperties（对于UObject）。对于Actor，BeginPlay也是一个选择，但OnConstruction在编辑器放置和运行时生成时都会调用，更通用。

陷阱二：与EditAnywhere或BlueprintReadWrite的混淆

UPROPERTY(EditAnywhere, BlueprintReadWrite, Meta=(ExposeOnSpawn=true)) // 可能不是你想要的效果 int32 ConfigValue;

这样声明，属性既可以在细节面板随时编辑（EditAnywhere），又可以在生成时设置。这可能导致混淆：一个在编辑器中预设了值的Actor，在蓝图里生成时又被传入一个新值，哪个优先级高？答案是：生成时传入的值会覆盖编辑器中设置的值。如果你希望一个属性只能在生成时设置，之后不可编辑，应该使用BlueprintReadOnly而不是BlueprintReadWrite。

UPROPERTY(BlueprintReadOnly, Meta=(ExposeOnSpawn=true)) // 更清晰：仅生成时可写，之后只读 int32 SpawnOnlyParameter;

陷阱三：用于动态变化频繁的属性ExposeOnSpawn不是为频繁变化的属性设计的。例如，如果你有一个每帧位置都更新的Actor，试图通过ExposeOnSpawn来设置其初始位置是可以的，但之后想通过其他方式修改这个属性，就要小心其“只读”语义（如果用了BlueprintReadOnly）带来的限制。

陷阱四：网络复制（Replication）的冲突如果一个属性同时标记了ExposeOnSpawn和Replicated，你需要理解其复制顺序。生成时设置的值会作为初始值，随后可能被服务器复制过来的值覆盖。对于关键的网络同步状态，通常更推荐使用RPC（远程过程调用）来确保一致性，而不是依赖ExposeOnSpawn的初始值和属性复制的竞态条件。

最佳实践总结：

1. 明确目的：仅对“一次性初始化参数”使用ExposeOnSpawn。
2. 权限收紧：优先使用BlueprintReadOnly，除非有后续修改的强烈需求。
3. 初始化时机：绝对不在构造函数中读取该值。将依赖逻辑放在OnConstruction或BeginPlay中。
4. 命名暗示：给这类变量起名如InitialDamage、SpawnScale，从名字上提醒开发者它的用途。
5. 文档注释：在代码注释中明确说明：“此变量仅在生成时通过ExposeOnSpawn设置，构造函数中无效。”

5. 调试技巧与常见问题排查实录

即使理解了所有规则，实际开发中还是会遇到各种诡异的问题。下面是我积累的一些调试经验和常见问题的排查清单。

5.1 UPROPERTY() 不显示在细节面板

这是最常见的问题。请按以下清单检查：

1. 编译了吗？修改USTRUCT/UCLASS头文件后，必须重新编译（编译，而不是仅仅热重载）。有时需要关闭编辑器再编译，或使用“Live Coding”的完全重新编译。
2. 有GENERATED_BODY()吗？在USTRUCT或UCLASS内部第一行。
3. 有UPROPERTY()宏吗？光有变量不行，必须有宏。
4. UPROPERTY的权限对吗？想要在细节面板编辑，至少需要EditAnywhere或EditDefaultsOnly。VisibleAnywhere只能看不能改。
5. 类别（Category）正确吗？检查细节面板是否展开了正确的分类，或者搜索一下变量名。
6. 是蓝图可访问的吗？如果希望蓝图也能设置，需要BlueprintReadWrite或BlueprintReadOnly（配合EditAnywhere）。
7. 头文件被正确包含了吗？确保包含该头文件的模块在.Build.cs文件中被正确添加依赖。

5.2 蓝图无法编译，提示“未知类型”或“无效变量类型”

当你在蓝图中尝试使用自定义的USTRUCT或UENUM作为变量类型时，可能会遇到此错误。

1. 检查BlueprintType：确保在USTRUCT()或UENUM()宏中包含了BlueprintType。
2. 检查模块依赖：你的游戏模块（如MyGame）必须在其.Build.cs文件中PublicDependencyModuleNames里添加定义该结构体/枚举的模块。如果FMyData定义在MyGame模块内，则其他模块需要依赖MyGame。
3. 尝试完全重新生成项目文件：有时需要删除Intermediate、Saved文件夹和*.sln文件，然后右键.uproject文件选择“Generate Visual Studio project files”，再重新编译。

5.3 序列化数据丢失或错误

游戏存档后，某些变量值恢复默认。

1. 确认UPROPERTY(SaveGame)：需要持久化的变量必须添加此说明符。
2. 检查变量初始化：确保在对象被创建时（构造函数或PostInitProperties），所有SaveGame变量都有合理的默认值，避免加载时出现未定义行为。
3. 验证序列化函数：如果你重写了Serialize函数，确保正确调用了父类版本，并且所有需要保存的变量都正确地归档（Ar <<）了。

5.4 ExposeOnSpawn 值未生效

在生成Actor的蓝图中设置了值，但Actor内部读到的还是默认值。

1. 检查读取时机：你是否在构造函数中读取？如果是，请移到OnConstruction或BeginPlay中。
2. 检查属性权限：确保属性是BlueprintReadWrite或至少BlueprintReadOnly（ExposeOnSpawn隐含了生成时的写入权限）。
3. 检查生成节点：确认你使用的是Spawn Actor from Class节点，并且该节点的“Spawn Transform”下方确实出现了你期望的输入引脚。有时引脚会被折叠，需要点击节点上的“+”号展开。
4. 调试输出：在OnConstruction中，使用UE_LOG或GEngine->AddOnScreenDebugMessage打印出该变量的值，确认是否被正确设置。

5.5 网络复制问题

USTRUCT作为可复制变量的一部分时，复制不正常。

1. 结构体本身需支持复制：结构体所有需要复制的成员都必须有UPROPERTY()且包含Replicated或ReplicatedUsing说明符。复制是按成员进行的。
2. 注意Replicated位置：Replicated是加在UPROPERTY上，而不是USTRUCT上。

   USTRUCT() struct FReplicatedData { GENERATED_BODY() UPROPERTY(Replicated) // 正确 int32 Health; // int32 Health; // 错误，没有UPROPERTY，不会被复制 };

3. 实现GetLifetimeReplicatedProps：对于包含USTRUCT的UCLASS，仍需在其GetLifetimeReplicatedProps函数中注册包含该结构体的属性。
4. 考虑RepNotify：如果结构体整体变化时需要通知，可以对包裹它的UPROPERTY使用ReplicatedUsing，并在回调函数中处理。

5.6 使用性能分析工具辅助调试

对于更深层次的问题，UE内置的工具非常有用：

• 反射查看器：在编辑器控制台输入ShowDebug Reflection或通过“窗口”->“开发者工具”->“反射查看器”，可以查看任何USTRUCT/UCLASS的完整反射信息，包括属性、元数据等，确认它们是否按预期暴露。
• 属性调试：在代码中使用FProperty系统进行动态查询和设置，但这属于高级用法。
• 网络调试：使用netdebug相关控制台命令（如NetDebug）来监视复制属性的更新情况。

写UE5 C++代码，尤其是与引擎反射系统深度交互的部分，就像在与一个规则严谨但文档不全的伙伴合作。USTRUCT、UENUM和ExposeOnSpawn这些特性，一旦掌握了它们的“脾气”，就能极大地提升开发效率和代码质量。核心就是记住：反射依赖宏，数据流动看时机，蓝图交互需权限。多写，多试，多踩坑，自然就熟了。当你再看到编辑器里漂亮的下拉菜单、整齐的属性面板，以及蓝图节点上那些自定义的引脚时，你会觉得这些严谨的规则都是值得的。