TSubclassOf比UClass*更安全，因其在编译期强制类型约束（如限定为AActor子类），编辑器提供下拉筛选与路径校验，且需配合StaticClass()设默认值、StaticLoadClass()动态加载，并始终校验IsValidLowLevel()和IsChildOf()后方可Spawn。
为什么TSubclassOf比UClass*更安全
因为 TSubclassOf<aactor></aactor> 在编译期就强制要求赋值的类必须是 AActor 或其子类，而裸指针 UClass* 可以指向任意类（包括 UObject、UAnimInstance 等），运行时才可能因类型不匹配崩溃。UE 编辑器还会为 TSubclassOf 提供下拉菜单和蓝图类过滤，避免手动输入错误路径。
在C++中声明和初始化TSubclassOf的正确方式
常见错误是直接用字符串或 StaticLoadObject 赋值，这绕过了类型检查且易出错。应优先走编辑器暴露 + 默认值设定：
- 声明时加
UPROPERTY(EditAnywhere, BlueprintReadOnly)，例如：UPROPERTY(EditAnywhere, BlueprintReadOnly) TSubclassOf<aenemycharacter> EnemyClass;</aenemycharacter> - 在构造函数中设默认值：
EnemyClass = AEnemyCharacter::StaticClass();（注意不是GetClass()） - 若需动态加载，必须先用
StaticLoadClass并显式 cast：EnemyClass = StaticLoadClass<aenemycharacter>(nullptr, TEXT("/Game/Blueprints/BP_Enemy.BP_Enemy_C")); </aenemycharacter>，否则返回空 - 禁止用
FindClass或LoadObject<uclass></uclass>直接赋给TSubclassOf—— 类型不匹配会导致编译失败或静默截断
使用前必须检查是否有效且可实例化
TSubclassOf 不保证所指类存在、未被重定向、或能被 SpawnActor 使用。常见崩溃场景：蓝图重命名后引用失效、类被设为 NotPlaceable、或继承链断裂。
- 始终用
IsValidLowLevel()和IsChildOf()双重校验：if (EnemyClass && EnemyClass->IsValidLowLevel() && EnemyClass->IsChildOf<aenemycharacter>())</aenemycharacter> - Spawn 前确认可生成：
if (EnemyClass->HasAnyClassFlags(CLASS_Abstract | CLASS_NotPlaceable))需跳过 - 蓝图类需启用
Can be used in Blueprint（在类设置里勾选Expose to Cinematics或Expose to Game） - 编辑器中拖入无效蓝图时，
TSubclassOf字段会显示黄色警告，但不会阻止编译 —— 运行时才nullptr
蓝图中传入C++函数时的类型对齐问题
蓝图调用 C++ 函数时，如果参数是 TSubclassOf<aactor></aactor>，必须确保蓝图端传入的是 AActor 子类（如 BP_Enemy_C），而非 UClass 引用或父类本身。
立即学习“C++免费学习笔记（深入）”；
- 蓝图节点输入口显示为“Class Reference”，但只接受具体子类 —— 若拖入
AActor本身，调用时TSubclassOf值为空 - C++ 函数声明中不要写成
TSubclassOf<uobject></uobject>来“兼容一切”，这会失去类型约束，且蓝图无法自动推导可选类列表 - 若需支持多态（比如敌人/道具/特效共用一个 Spawn 函数），用模板函数或多个重载，而不是降级为
UClass*
NotPlaceable 标志和重定向残留 —— 即使 TSubclassOf 显示正常，Spawn 也可能返回空 Actor。每次重构蓝图类名或移动路径后，务必重新检查所有引用点。 
