UWorld::SpawnActor必须先获取有效UWorld*指针，因该函数属UWorld实例而非静态方法；需通过GetWorld()或GEngine->GetWorldFromContextObject等途径获取，并确保非nullptr且在PIE/游戏运行时调用。
UWorld::SpawnActor 为什么必须先获取 World 指针
在非 Actor 类（比如 GameMode、PlayerController 或纯工具类）里直接调用 SpawnActor 会编译失败或运行时崩溃，因为这个函数属于 UWorld 实例，不是静态方法。常见错误是写成 AMyActor::SpawnActor(...) 或直接裸调 SpawnActor —— 这根本不存在。
正确做法是先拿到有效的 UWorld*，最稳妥的是从当前 Actor 获取（如在 ACharacter 子类中）：GetWorld()；若在 GameMode 中，可用 GetWorld()；若在纯 C++ 工具类中，需通过 GEngine->GetWorldFromContextObject(...) 或传入已有 Actor 引用。
- 确保
GetWorld() != nullptr，尤其在构造函数、BeginDestroy或编辑器预览阶段，World可能为空 - 编辑器中“模拟”或“PIE”启动后，
World才真正可用；构造函数里调用必崩 - 多人游戏下，服务端调用才实际生成 Actor；客户端调用默认不生效（除非设
bNetSpawnable = true且走 RPC）
FTransform 和 FVector 参数怎么配才准确定位
SpawnActor 接收位置的方式有两种：一是用 FVector + FRotator 重载，二是用 FTransform。后者更推荐，因为能一并控制缩放（虽然 Actor 通常忽略非均匀缩放），且避免旋转/位置顺序错乱。
常见误区是把世界坐标直接传给 FVector(100, 200, 300) 就以为完事——其实还要确认坐标系是否匹配。UE 默认 Z 向上，X 向前，Y 向右；如果你的数据来自外部（比如地图坐标系或算法输出），可能需要手动交换 Y/Z 或取负。
-
FTransform构造顺序是FTransform(Rotation, Location, Scale)，Scale 一般用FVector::OneVector - 如果 Actor 有根组件（如
USceneComponent），其SetWorldLocation行为受bAbsoluteLocation影响，但SpawnActor始终以世界坐标解释Location - 动态生成后想微调，别再用
SetActorLocation覆盖——它可能触发物理或碰撞，不如初始化时一步到位
动态 Spawn 的 Actor 怎么确保蓝图子类也能被正确实例化
用 C++ 写 SpawnActor 只能生成 C++ 类本身，无法自动加载蓝图子类。要支持蓝图扩展，必须用 UClass* 参数版本，并确保该 UClass 是蓝图编译后的结果。
典型流程：在编辑器里把蓝图类拖到 C++ 头文件中声明一个 UPROPERTY(EditAnywhere) 的 TSubclassOf，然后在代码中用它作为模板：
if (MyBlueprintClass && MyBlueprintClass->IsChildOf(AActor::StaticClass()))
{
AActor* Spawned = GetWorld()->SpawnActor<aactor>(MyBlueprintClass, SpawnTransform);
}</aactor>
- 蓝图类未编译或路径错误时，
MyBlueprintClass为nullptr，必须判空 - 不能用字符串路径（如
"Blueprint'/Game/BP_MyActor.BP_MyActor'"）在运行时硬编码加载——这依赖StaticLoadObject，且热重载后地址失效 - 若蓝图设置了
Default Pawn Class或Player Controller，它们的生成逻辑独立于SpawnActor，别混用
Spawn 出来的 Actor 不显示、不响应、甚至立刻销毁？检查这几个点
生成成功但看不到，大概率不是坐标错，而是生命周期或上下文问题。最常被忽略的是：Actor 是否被添加到 World 的 Actor 数组中、是否有有效 Outer、是否被 GC 回收。
- 确认返回值非
nullptr；若为nullptr，说明 Spawn 失败（常见原因：Class 无效、World 不可写、内存不足） - 检查 Actor 的
bHidden、bHiddenInGame、RootComponent是否为nullptr或未注册（SetupAttachment后需调RegisterComponent） - 若在 Tick 或高频率循环里反复 Spawn，没配
Destroy逻辑，会快速吃光内存；建议用对象池或显式调用Destroy() - 使用
SpawnActorDeferred+FinishSpawning可绕过初始碰撞检测，适合需要精确控制初始化时机的场景（如生成后立即设置变量再激活）
坐标只是起点，真正卡住人的往往是 World 上下文、UClass 有效性、以及 Actor 自身组件的初始化完整性。每次 Spawn 前，花三秒看一眼 GetWorld() 和 MyClass 是不是真活着，比调十次坐标有用得多。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
