开场刚接手一个 UE4 项目时，团队里的新人盯着 Class Hierarchy 面板问我：这个GameMode、PlayerController、Pawn、TriggerVolume都挂着Actor父类，凭什么连一棵树、一盏灯也是Actor？更让人崩溃的是，逻辑到底写到哪——是GameMode还是Actor？是PlayerState还是Component？这种迷茫几乎每个 UE4 开发者都经历过。表面上看 UE4 的对象模型像一棵庞大的类继承树，实际上它围绕着UWorld（世界）、Actor（演员）、Component（组件）三层结构展开，而这三层之下还有一块常被忽略的地基——UObject 反射系统。理解了这套层级，"游戏规则写在 GameMode、数据放在 PlayerState"这类潜规则就自然讲得通了。零、地基：UObject 反射系统为什么重要在讲三层结构之前，先回答一个更底层的问题：为什么 UE4 里的类都要写UCLASS()、UPROPERTY()、GENERATED_BODY()这些宏？这些宏会被 Unreal Header Tool（UHT）扫描，生成反射元数据（字段类型、偏移量、GC 引用关系、网络复制条件）。有了反射，引擎才能在 C++ 这种"编译后不保