UCLASS和GENERATED_BODY缺一不可，前者标记类供UHT生成反射元数据，后者插入序列化、GC、蓝图绑定等必需代码；漏写会导致链接错误、蓝图不可见、变量失效或运行时崩溃。
直接上手写C++类就能用，但必须过UCLASS+GENERATED_BODY这道门槛，漏一个编译就报错或运行时崩溃。
UCLASS和GENERATED_BODY为什么不能少
UE的C++不是标准C++，所有要进反射系统的类（比如AActor子类、UObject子类）都得显式声明。UCLASS()告诉UHT（Unreal Header Tool）“这个类要生成元数据”，GENERATED_BODY()则插入引擎自动生成的代码——包括序列化函数、GC注册、蓝图绑定入口等。没它，编辑器看不到变量，蓝图调不了函数，GC不回收对象，甚至FindObject都查不到实例。
- 常见错误现象：
LNK2019 unresolved external symbol（链接失败）、蓝图节点列表为空、变量在细节面板灰掉 - 构造函数里漏掉
PrimaryActorTick.bCanEverTick = true;会导致Tick()完全不执行，但不会报错 - GENERATED_BODY()必须放在类定义的**第一行非注释位置**，否则宏展开错位，UHT解析失败
UPROPERTY怎么选说明符才不翻车
UPROPERTY不是装饰，它决定变量是否参与序列化、能否被蓝图读写、是否进GC追踪。选错说明符，轻则编辑器改不动值，重则对象泄漏或加载存档时崩溃。
-
UPROPERTY()裸用＝只参与GC和序列化，编辑器不可见、蓝图不可读写 -
UPROPERTY(EditAnywhere)：编辑器可见可改，但蓝图默认不能读——要加BlueprintReadWrite才开放 -
UPROPERTY(VisibleAnywhere)：编辑器只读，适合显示计算结果（如FVector Location） - 含TArray、TMap等容器的成员，必须加UPROPERTY，否则容器内容不序列化、不GC，运行时可能野指针
热重载失败的三个高频原因
UE的热重载很便利，但不是万能的。以下情况会强制重启编辑器，打断开发流：
- 修改了类的继承关系（比如把
public AActor改成public ACharacter） - 增删了UCLASS宏标记的类里的UPROPERTY或UFUNCTION——UHT需重新扫描头文件并生成新代码
- 改动了
GENERATED_BODY()所在类的头文件依赖链（比如改了前置声明的USTRUCT定义） - 小技巧：改.cpp里的逻辑函数（如
Tick()实现）基本都能热重载；改.h里的反射标记，大概率要等UHT跑完再加载
蓝图调用C++函数的硬性条件
光写UFUNCTION(BlueprintCallable)不够，还得满足三要素：函数不能是private、参数类型得是UE支持的反射类型、不能有未标记的复杂结构体传参。
- 错误示例：
void DoSomething(FMyStruct Data)——若FMyStruct没加USTRUCT()和GENERATED_BODY()，蓝图节点根本不出现在面板里 - 数组参数必须显式标注：
UFUNCTION(BlueprintCallable) void ProcessArray(const TArray& Values); - 返回值为UObject子类时，需加
BlueprintPure或确保返回对象已AddToRoot()，否则蓝图拿到空指针 - 调试建议：在函数开头加
UE_LOG(LogTemp, Warning, TEXT("Called from BP"));，确认是否真被调用
最易被忽略的是UHT的滞后性——它只在头文件保存、项目编译或编辑器焦点切回时触发扫描。改完UCLASS类的.h后，哪怕VS编译成功，也得手动点一下编辑器窗口，等右下角提示“Recompiling header files…”完成，蓝图才能看到更新。这个延迟没有日志提示，纯靠经验判断。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
