当前位置：首页 > news >正文

《Unreal 对 C++ 做了什么》系列 04. USTRUCT 与 UPROPERTY：数据结构的反射化与变量管理

news 2026/5/27 1:23:19

《Unreal 对 C++ 做了什么》系列 (04/54)

在标准 C++ 中，如果你定义了int32 Health;，编译器只会在内存里留出 4 个字节。程序运行起来后，除了你的代码，没有人知道这 4 个字节代表“血量”。

虚幻引擎通过USTRUCT和UPROPERTY为这段内存贴上了**“身份标签”**。

虽然USTRUCT在 C++ 层面上是个结构体，但在 UHT 看来，它是一个**“被剥夺了部分权力的 UClass”**。

UObject都有一个在引擎内部的路径（如/Game/Maps/Level1.ActorA），但USTRUCT没有。它必须寄生在某个UObject的内存块里，或者作为一个局部变量存在。

当你在USTRUCT里写下GENERATED_BODY()时，UHT 会生成一个StaticStruct()函数。

标准 C++ 痛点：你无法通过变量名字符串（如 “Health”）去访问结构体成员。
UE 解决方案：UScriptStruct。每一个USTRUCT都有一个对应的UScriptStruct元数据对象。它记录了结构体的大小、对齐方式以及每个成员的偏移量。

这是虚幻 C++ 的灵魂宏。我们将它拆解为三个层面：

这是新手最容易忽视的一点。

裸指针：AActor* MyActor;。如果MyActor在关卡里被销毁了，你的指针依然指向原来的地址（野指针），访问即崩溃。
UPROPERTY 指针：UPROPERTY() AActor* MyActor;。当该 Actor 被销毁时，UE 会遍历所有引用它的UPROPERTY指针，并**强行将其设为nullptr**。这就是为什么 UE 推荐你访问指针前先做if(MyActor)判断。

说明符不是注释，它们直接改变了 UHT 生成的代码逻辑：

**EditAnywherevsEditInstanceOnly**：
EditAnywhere：在蓝图类（原型）和场景实例中都能改。
EditInstanceOnly：只能在摆放到场景里的那个“分身”上改。这在内存上涉及到CDO (Class Default Object)的数据覆盖机制。
BlueprintReadOnly：UHT 会在生成的代码中，拒绝为该变量生成“写入”权限的反射接口，即使你在 C++ 里它是public的。

UE 的编辑器面板（Details Panel）其实是一个“内存编辑器”。
当你拖动滑动条修改血量时，流程如下：

编辑器通过反射找到该变量的FProperty对象。
FProperty存储了相对于类起始位置的Offset（偏移量）。
编辑器计算：Address = (Byte*)ObjectInstance + Offset。
直接往这个内存地址里写值。
这就是为什么即使你的变量是private的，只要加了UPROPERTY(EditAnywhere)，编辑器依然能改它——因为它绕过了 C++ 访问权限，直接操作内存。

如果你的容器里装的是UObject*，必须加UPROPERTY。

// 错误：GC 扫描不到容器内部，里面的 Actor 随时会被回收，留下满地野指针TArray<AActor*>MyActors;// 正确：UE 的 GC 系统会递归扫描容器内部的每一个元素，保护它们的生命周期UPROPERTY()TArray<AActor*>MyActors;