三亩地 三亩地SAN MU DI · CODE DIARY
交流投稿
ARTICLE DETAIL

日记详情

真实记录编程学习的某一天，欢迎挑你感兴趣的翻一翻。

首页/学习日记/日记详情

UE5 C++开发：头文件管理与类操作全流程解析

发布时间：2026/8/4 14:19:33 三亩地 编程学习日记
UE5 C++开发：头文件管理与类操作全流程解析

1. 项目概述：为什么UE5 C++的头文件与类是基石？

如果你是从蓝图转向UE5 C++的开发者，或者正在学习UE5 C++，那么“头文件”和“类”这两个词，你肯定不陌生，但也可能最让你头疼。蓝图里拖拖拽拽，节点连一连，功能就出来了，但在C++里，你得先写一个.h文件，再写一个.cpp文件，然后才能开始“真正”的编码。很多人会问：为什么这么麻烦？能不能像写脚本一样，一个文件搞定？

这正是UE5 C++开发与普通C++或脚本语言开发的核心区别，也是其强大与严谨性的体现。这个项目，就是要彻底拆解UE5 C++开发中头文件管理与类操作的全流程。它不是一个简单的语法教程，而是一套从工程实践出发的“生存指南”。在UE5庞大的代码库和独特的反射、序列化、垃圾回收机制下，头文件怎么写、类怎么声明、宏怎么用，直接决定了你的代码能否被引擎正确识别、编译，以及后续的迭代、调试、多人协作是否顺畅。

我见过太多项目，初期为了图快，把大量实现塞在头文件里，或者类的设计混乱不堪，导致后期编译时间爆炸、链接错误频发、简单的功能改动牵一发而动全身。这个流程解析，就是要帮你从第一天起就建立正确的开发习惯，理解每一个操作背后的“为什么”，让你写出的代码不仅是能跑的，更是健壮、可维护、符合UE5最佳实践的。无论你是想创建自定义的Actor、开发一个新的游戏模块，还是为项目编写底层工具，这套流程都是你必须掌握的“内功”。

2. 核心概念与UE5工程结构解析

在动手写代码之前，我们必须先理解UE5 C++项目的基本构成。这不同于你创建一个简单的控制台程序，UE5为我们搭建了一个复杂的、但高度集成的脚手架。

2.1.uproject与.Build.cs：项目的入口与模块定义

当你用Unreal Editor新建一个C++项目时，会生成一个以.uproject为后缀的文件。这个文件是项目的“身份证”，它描述了项目的基本信息、模块依赖和启动配置。但对我们开发者而言，更关键的是项目目录下的Source文件夹。

在Source文件夹里，你会看到至少一个以项目名命名的文件夹（例如MyProject），里面包含两个核心文件：项目名.Build.cs（如MyProject.Build.cs）和项目名.h/.cpp。项目名.Build.cs文件是Unreal Build Tool（UBT）的构建脚本，它定义了本模块（Module）的编译规则。

// MyProject.Build.cs 示例 using UnrealBuildTool; public class MyProject : ModuleRules { public MyProject(ReadOnlyTargetRules Target) : base(Target) { // 模块类型：游戏模块（Game）、编辑器模块（Editor）等 PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs; // 公有依赖模块：其他模块要使用本模块时，也需要链接这些模块 PublicDependencyModuleNames.AddRange(new string[] { "Core", "CoreUObject", "Engine", "InputCore" }); // 私有依赖模块：仅本模块内部实现需要，不对外暴露 PrivateDependencyModuleNames.AddRange(new string[] { }); // 如果你要使用Slate UI，可能需要添加 "Slate", "SlateCore" // PrivateDependencyModuleNames.AddRange(new string[] { "Slate", "SlateCore" }); } }

注意：PublicDependencyModuleNames和PrivateDependencyModuleNames的区分至关重要。如果你在模块A的头文件中包含了模块B的头文件，那么模块B必须被声明为模块A的Public依赖。如果仅在.cpp文件中使用，则可以声明为Private依赖。错误配置是导致“未找到类型”编译错误的常见原因。

2.2 头文件（.h）与源文件（.cpp）的职责划分

这是C++的通用概念，但在UE5的语境下，其边界更加清晰和重要。

  • 头文件（.h）：声明的场所。它告诉编译器“有什么”。

    • 类声明：包括类名、继承关系、成员变量（UPROPERTY/USPROPERTY）、成员函数（UFUNCTION）的声明。
    • 宏定义：特别是UE5特有的宏，如GENERATED_BODY()。
    • 类型别名（using/typedef）。
    • 前置声明（Forward Declaration）：为了减少编译依赖，如果只需要用到某个类的指针或引用，尽量使用class AMyClass;前置声明，而不是直接#include “AMyClass.h”。
    • 核心原则：头文件应该尽可能“轻量”和“稳定”。避免在头文件中包含其他复杂的头文件（尤其是引擎核心头文件如Engine.h），也避免放置模板的复杂实现（除非是内联函数）。这能显著减少编译时间。

  • 源文件（.cpp）：定义的场所。它告诉编译器“是什么”和“怎么做”。

    • 成员函数的具体实现。
    • 静态变量的定义。
    • 全局函数的实现。
    • 在这里，你可以根据需要包含各种头文件，因为.cpp文件的改动通常只导致自身重新编译，影响范围小。

2.3 UE5特有的宏：GENERATED_BODY()与反射宏

这是UE5 C++区别于原生C++的灵魂所在。UE5拥有一套强大的反射系统，允许在运行时查询类、属性和函数的信息。蓝图能与C++交互，编辑器细节面板能显示变量，网络复制能工作，都依赖于这套系统。

  • GENERATED_BODY()：必须放在类声明的开头（紧随UCLASS()等宏之后）。这个宏展开后，会包含一系列由Unreal Header Tool（UHT）在编译前生成的代码，为这个类注入反射支持、序列化支持等基础设施。没有它，你的UClass在引擎中就无法被正确识别。

  • UCLASS()、USTRUCT()、UENUM()、UPROPERTY()、UFUNCTION()：这些是属性说明符宏。

    • UCLASS([specifiers])：标记一个类参与反射。specifiers可以控制类的行为，如Blueprintable（可被蓝图继承）、NotBlueprintable、Within=APlayerController（限定其外部对象）等。
    • UPROPERTY([specifiers])：标记一个成员变量参与反射。这是最常用的宏之一，其说明符极其丰富：
      // 在头文件中 UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category="Health") float CurrentHealth; UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Health", meta=(ClampMin=0.0, ClampMax=1000.0)) float MaxHealth; UPROPERTY(BlueprintReadWrite, Category="Inventory") TArray<UItem*> InventoryItems; UPROPERTY(ReplicatedUsing=OnRep_PlayerName) // 网络复制，变化时调用OnRep_PlayerName FString PlayerName;
      • VisibleAnywhere：在属性窗口（如Details面板）中可见，但不可编辑。
      • EditAnywhere：在属性窗口中可见且可编辑。
      • BlueprintReadOnly/BlueprintReadWrite：决定蓝图是否能读取或写入该变量。
      • Category：在编辑器中属性分组的类别。
      • meta：提供额外的元数据，如取值范围、工具提示等。
    • UFUNCTION([specifiers])：标记一个成员函数参与反射。
      UFUNCTION(BlueprintCallable, Category="Character|Movement") void Jump(); UFUNCTION(BlueprintNativeEvent, Category="Damage") // 有默认C++实现（后缀_Implementation），也可被蓝图覆盖 void TakeDamage(float DamageAmount); UFUNCTION(Server, Reliable, WithValidation) // 标记为服务器函数，用于网络RPC void ServerFireWeapon();
      • BlueprintCallable：蓝图可以调用此函数。
      • BlueprintImplementableEvent：这是一个纯虚事件，必须在蓝图中实现。
      • BlueprintNativeEvent：有一个默认的C++实现（函数名后加_Implementation），但蓝图可以覆盖它。
      • Server/Client/NetMulticast：用于网络RPC（远程过程调用）。

实操心得：刚开始时，你可能会忘记在变量或函数前添加这些宏，导致它们在编辑器中“不可见”。养成习惯：每当声明一个希望与编辑器或蓝图交互的变量或函数时，立刻思考是否需要加上UPROPERTY或UFUNCTION以及合适的说明符。UHT会在编译前检查这些宏，如果使用错误，会给出相对清晰的错误提示。

3. 头文件管理的艺术与实践

头文件管理是大型C++项目（尤其是UE5项目）性能和维护性的关键。糟糕的头文件包含关系是编译时间长的罪魁祸首。

3.1 前置声明 vs.#include

这是减少编译依赖的核心技术。

  • 使用#include的场景：

    1. 当你需要知道某个类的完整定义时，例如：
      • 继承自该类：class AMyCharacter : public ACharacter
      • 以值类型使用该类成员变量：FVector MyLocation;（但FVector是内置类型，通常已前置声明在全局）
      • 在函数体中创建该类的实例。
      • 实际上，在.h文件中，对于UE5的UObject类，即使继承，也常常只需要前置声明，因为GENERATED_BODY()会处理。但对于非UObject的普通C++类或结构体，继承时需要#include。

  • 使用前置声明的场景：

    1. 仅使用类的指针或引用：class AMyWeapon;AMyWeapon* MyWeaponPtr;
    2. 在函数声明中使用指针或引用作为参数或返回类型：void UseWeapon(AMyWeapon* Weapon);
    3. 在UE5中，对于绝大多数UObject派生类，在头文件中都应该优先使用前置声明。

最佳实践示例：

// MyCharacter.h - 良好的头文件 #pragma once #include "CoreMinimal.h" // 必须包含，它又包含了最基础的类型和宏，且经过优化 #include "GameFramework/Character.h" // 因为我们要继承自ACharacter，所以需要其定义 #include "MyCharacter.generated.h" // UHT生成的头文件，必须最后包含 // 前置声明我们需要的类 class AMyWeapon; class UMyHealthComponent; UCLASS() class AMyCharacter : public ACharacter { GENERATED_BODY() public: // 构造函数等声明... UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category="Components") UMyHealthComponent* HealthComp; // 使用指针，只需前置声明 UFUNCTION(BlueprintCallable) void EquipWeapon(AMyWeapon* NewWeapon); // 参数为指针，只需前置声明 private: // 私有成员也可以使用前置声明的指针 AMyWeapon* CurrentWeapon; }; // MyCharacter.cpp - 对应的源文件 #include "MyCharacter.h" #include "MyWeapon.h" // 在.cpp中，因为要操作AMyWeapon，所以需要包含其头文件 #include "MyHealthComponent.h" #include "Engine/Engine.h" // 如果需要使用GEngine等 // ... 其他必要的包含

3.2 预编译头文件（PCH）的理解

你可能在.Build.cs中看到PCHUsage = PCHUsageMode.UseExplicitOrSharedPCHs;。PCH（Precompiled Header）是一种编译优化技术。UE5会预编译一些极其常用且稳定的头文件（如CoreMinimal.h中的内容），生成一个.pch文件。在编译每个.cpp文件时，编译器可以直接加载这个预编译好的二进制数据，而不是反复解析成千上万行的头文件代码，从而极大提升编译速度。

CoreMinimal.h就是UE5为你模块准备的“最小化PCH”。你应该始终在.h文件中包含#include "CoreMinimal.h"，而不是包含诸如Engine.h、UnrealEd.h这样的庞大头文件。在.cpp文件中，你可以根据需要包含更具体的头文件。

3.3 防止头文件重复包含：#pragma once

在现代C++编译器中，#pragma once是防止头文件被多次包含进同一个翻译单元的标准且高效的方式。它告诉编译器：这个文件只编译一次。你会在所有UE5生成的头文件顶部看到它。务必在你自定义的头文件中也使用它。

4. 类的声明、定义与UE5生命周期

在UE5中创建和使用类，有一套固定的流程和约定。

4.1 使用编辑器创建新类（推荐给初学者）

这是最安全、最标准的方式。在内容浏览器中右键 -> 蓝图/类 -> 选择父类（如Actor、Pawn、Object等）-> 输入类名和路径 -> 创建。编辑器会自动为你生成正确的.h和.cpp文件骨架，包括所有必要的宏、默认构造函数和#include语句。这能避免因手动创建文件而遗漏关键宏或包含关系。

4.2 手动创建类的标准流程

当你需要创建非UObject的普通C++类，或者想更精细控制时，需要手动创建。

  1. 创建头文件（.h）：

    • 在Source/项目名/Public或Private目录下创建。通常，希望被其他模块使用的类放在Public，仅内部使用的放在Private。
    • 写入#pragma once。
    • 包含CoreMinimal.h和生成的.generated.h文件（如果是UObject）。
    • 使用UCLASS()等宏声明类。
    • 声明成员变量（用UPROPERTY修饰）和成员函数（用UFUNCTION修饰）。
    • 遵循UE5的命名约定：类以A开头（继承自AActor）、U开头（继承自UObject）、F开头（普通结构体/类）、E开头（枚举）、I开头（接口）等。

  2. 创建源文件（.cpp）：

    • 在对应目录（Public对应Private，反之亦然？通常.cpp都放在Private文件夹）创建同名.cpp文件。
    • 包含对应的头文件。
    • 包含其他必要的头文件。
    • 实现所有声明的函数，包括构造函数和由BlueprintNativeEvent标记的函数的_Implementation版本。

示例：创建一个简单的可拾取物品Actor

// Public/PickupItem.h #pragma once #include "CoreMinimal.h" #include "GameFramework/Actor.h" #include "PickupItem.generated.h" // 注意：这是“项目名.generated.h”？不，是“类名.generated.h”。UHT会为每个头文件生成对应的.generated.h。 UCLASS() class MYPROJECT_API APickupItem : public AActor { GENERATED_BODY() public: APickupItem(); // 构造函数 protected: virtual void BeginPlay() override; UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category="Pickup") class UStaticMeshComponent* MeshComponent; // 使用前置声明 UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Pickup") FName ItemID; UFUNCTION(BlueprintCallable, Category="Pickup") void OnPickedUp(class AMyCharacter* PickingCharacter); UFUNCTION(BlueprintNativeEvent, Category="Pickup") void OnPickupEffect(); virtual void OnPickupEffect_Implementation(); // BlueprintNativeEvent的默认实现 };
// Private/PickupItem.cpp #include "PickupItem.h" #include "Components/StaticMeshComponent.h" // 需要UStaticMeshComponent的定义 #include "MyCharacter.h" // 需要AMyCharacter的定义 #include "Engine/StaticMesh.h" APickupItem::APickupItem() { PrimaryActorTick.bCanEverTick = false; // 不需要每帧Tick，节省性能 // 创建并设置根组件（可选，但推荐） MeshComponent = CreateDefaultSubobject<UStaticMeshComponent>(TEXT("MeshComp")); RootComponent = MeshComponent; // 设置默认网格（可选） static ConstructorHelpers::FObjectFinder<UStaticMesh> MeshFinder(TEXT("/Game/Assets/Pickups/HealthPack.HealthPack")); if (MeshFinder.Succeeded()) { MeshComponent->SetStaticMesh(MeshFinder.Object); } ItemID = TEXT("HealthPack_Small"); } void APickupItem::BeginPlay() { Super::BeginPlay(); // 初始化逻辑 } void APickupItem::OnPickedUp(AMyCharacter* PickingCharacter) { if (PickingCharacter) { // 处理拾取逻辑，例如恢复生命值 UE_LOG(LogTemp, Log, TEXT("%s picked up by %s"), *GetName(), *PickingCharacter->GetName()); OnPickupEffect(); // 调用蓝图可覆盖的效果函数 Destroy(); // 拾取后销毁自身 } } void APickupItem::OnPickupEffect_Implementation() { // 默认效果，比如播放一个声音或粒子 // 蓝图可以覆盖这个函数实现更复杂的效果 }

4.3 类的生命周期与关键函数

了解UE5中Actor/Object的生命周期函数，对于编写正确的逻辑至关重要。

  • 构造函数 (::ClassName): 在对象被创建时调用（如NewObject、SpawnActor）。注意：此时世界场景（World）可能还未完全初始化，不能访问其他可能尚未创建的Actor。常用于初始化默认属性、创建子组件（CreateDefaultSubobject）。
  • BeginPlay(): 当Actor被放入世界并准备开始游戏逻辑时调用。这是进行初始化的安全位置，可以访问其他Actor。
  • Tick(float DeltaTime): 每帧调用。需要谨慎使用，保持其中逻辑轻量。可以通过PrimaryActorTick.bCanEverTick = false在构造函数中关闭。
  • EndPlay(const EEndPlayReason::Type EndPlayReason): 当Actor被从世界移除时调用（如销毁、关卡切换）。这是进行资源清理、取消定时器、断开事件绑定的地方。
  • 析构函数 (::~ClassName): 在C++对象内存被释放时调用。对于UObject，由于UE5的垃圾回收机制，你不应该依赖析构函数来做关键清理工作，因为析构的时机不确定。清理工作应在EndPlay或特定的销毁函数中进行。

注意事项：在构造函数中，避免执行复杂的逻辑或依赖其他可能尚未初始化的系统。使用CreateDefaultSubobject来创建组件，但不要尝试在构造函数中获取或设置依赖于游戏状态的属性。将这些操作放到BeginPlay中。

5. 实战：构建一个简单的交互系统

让我们通过一个稍微复杂的例子，串联头文件管理和类操作。假设我们要创建一个Interactable接口，任何实现了该接口的Actor都可以被玩家角色交互。

5.1 创建接口类

接口在UE5中是一种特殊的UClass，它只声明函数，不包含实现和成员变量。

// Public/InteractableInterface.h #pragma once #include "CoreMinimal.h" #include "UObject/Interface.h" #include "InteractableInterface.generated.h" UINTERFACE(MinimalAPI, Blueprintable) class UInteractableInterface : public UInterface { GENERATED_BODY() }; class MYPROJECT_API IInteractableInterface { GENERATED_BODY() public: // 声明一个蓝图可调用、可实现的交互函数 UFUNCTION(BlueprintCallable, BlueprintNativeEvent, Category="Interaction") void OnInteract(AActor* Interactor); };

注意这里有两个类：UInteractableInterface（UObject包装器）和IInteractableInterface（实际的C++接口类）。我们通常在代码中引用IInteractableInterface。

5.2 创建一个可交互的灯Actor

// Public/InteractiveLight.h #pragma once #include "CoreMinimal.h" #include "GameFramework/Actor.h" #include "InteractableInterface.h" // 包含接口头文件 #include "InteractiveLight.generated.h" UCLASS() class MYPROJECT_API AInteractiveLight : public AActor, public IInteractableInterface // 继承接口 { GENERATED_BODY() public: AInteractiveLight(); protected: virtual void BeginPlay() override; UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category="Components") class UPointLightComponent* PointLightComponent; UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Light") bool bIsOn; UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Light", meta=(EditCondition="bIsOn")) // 仅当bIsOn为true时可编辑 float LightIntensity; public: // 实现接口函数 virtual void OnInteract_Implementation(AActor* Interactor) override; };
// Private/InteractiveLight.cpp #include "InteractiveLight.h" #include "Components/PointLightComponent.h" AInteractiveLight::AInteractiveLight() { PrimaryActorTick.bCanEverTick = false; PointLightComponent = CreateDefaultSubobject<UPointLightComponent>(TEXT("PointLight")); RootComponent = PointLightComponent; bIsOn = true; LightIntensity = 5000.0f; } void AInteractiveLight::BeginPlay() { Super::BeginPlay(); PointLightComponent->SetIntensity(bIsOn ? LightIntensity : 0.0f); } void AInteractiveLight::OnInteract_Implementation(AActor* Interactor) { // 切换灯光状态 bIsOn = !bIsOn; PointLightComponent->SetIntensity(bIsOn ? LightIntensity : 0.0f); // 可以在这里播放声音或粒子效果 UE_LOG(LogTemp, Log, TEXT("Light interacted by %s. Now is %s"), *Interactor->GetName(), bIsOn ? TEXT("ON") : TEXT("OFF")); }

5.3 在角色类中实现交互逻辑

// 在MyCharacter.h中添加 public: UFUNCTION(BlueprintCallable, Category="Interaction") void PerformInteraction(); UPROPERTY(EditAnywhere, BlueprintReadWrite, Category="Interaction") float InteractionRange;
// 在MyCharacter.cpp中实现 #include "MyCharacter.h" #include "InteractableInterface.h" // 需要接口定义 #include "DrawDebugHelpers.h" // 用于调试绘制 #include "Engine/World.h" void AMyCharacter::PerformInteraction() { FVector Start = GetActorLocation(); FVector End = Start + GetActorForwardVector() * InteractionRange; FHitResult HitResult; FCollisionQueryParams QueryParams; QueryParams.AddIgnoredActor(this); // 忽略自己 bool bHit = GetWorld()->LineTraceSingleByChannel(HitResult, Start, End, ECC_Visibility, QueryParams); #if ENABLE_DRAW_DEBUG // 调试时绘制射线 DrawDebugLine(GetWorld(), Start, End, bHit ? FColor::Green : FColor::Red, false, 2.0f); #endif if (bHit && HitResult.GetActor()) { // 检查命中的Actor是否实现了IInteractableInterface接口 if (HitResult.GetActor()->Implements<UInteractableInterface>()) { // 调用接口函数 IInteractableInterface::Execute_OnInteract(HitResult.GetActor(), this); } } }

这个例子展示了如何通过接口实现松耦合的交互系统。灯Actor不需要知道具体是哪个角色交互了它，角色也不需要知道灯的具体实现，它们只通过IInteractableInterface这个契约进行通信。这是UE5中非常常用且优秀的设计模式。

6. 编译、调试与常见问题排查

即使流程正确，在UE5 C++开发中，你依然会遇到各种编译和运行时问题。

6.1 编译流程与Unreal Header Tool (UHT)

UE5的C++编译不是简单的调用MSVC或Clang。它有一个预处理步骤，由Unreal Header Tool (UHT) 执行。UHT会扫描所有包含特殊宏（如UCLASS,UPROPERTY）的头文件，生成必要的反射代码（.generated.h和.generated.cpp文件）。因此，如果你修改了头文件中的UHT相关宏，必须重新生成项目文件或确保UHT重新运行。

  • 在Visual Studio中：通常右键点击.uproject文件，选择“Generate Visual Studio project files”即可。
  • 在命令行或Rider中：运行项目根目录下的GenerateProjectFiles.bat（Windows）或相应脚本。

6.2 常见编译错误与解决方案

  1. “无法打开源文件xxxx.generated.h”：

    • 原因：UHT没有成功运行，或者生成的文件路径不对。
    • 解决：重新生成项目文件。检查头文件中的#include "xxxx.generated.h"语句，确保文件名与当前头文件名一致（区分大小写）。

  2. “未定义的标识符Uxxxx” 或 “不是AActor的成员”：

    • 原因：最常见的原因是缺少包含头文件或模块依赖未正确配置。
    • 解决：
      • 检查是否在.cpp文件中包含了必要的头文件。
      • 检查.Build.cs文件中的PublicDependencyModuleNames或PrivateDependencyModuleNames，确保依赖了目标类所在的模块。例如，如果你使用了UMaterial，可能需要添加"RenderCore"或更具体的模块（通常"Engine"模块已包含大部分基础类）。

  3. “链接错误 LNKxxxx”：

    • 原因：通常是因为声明了函数（包括BlueprintNativeEvent的_Implementation版本）但没有提供定义，或者模块依赖关系错误导致找不到符号。
    • 解决：检查所有声明的函数是否都有对应的实现体。对于BlueprintNativeEvent，确保你实现了_Implementation函数，而不是原函数名。

  4. “循环包含”错误：

    • 原因：A.h包含了B.h，B.h又包含了A.h。
    • 解决：使用前置声明打破循环。如果A.h只需要B的指针，就在A.h中前置声明class B;，然后在A.cpp中包含B.h。仔细审视类的设计，循环依赖可能意味着职责划分不清，考虑引入接口或前向声明。

6.3 调试技巧

  • 使用UE_LOG：这是最基础的调试手段。在代码中插入UE_LOG(LogTemp, Warning, TEXT("Variable Value: %f"), MyFloat);。输出会显示在编辑器的“输出日志”窗口。
  • 使用check()和ensure()：
    • check(MyPtr != nullptr);：如果条件为假，在开发构建中会触发断言，中断程序并定位到错误行。用于捕捉绝对不应该发生的错误。
    • if (ensure(MyPtr != nullptr)) { ... }：如果条件为假，会记录一次错误（在开发和非发布构建中），但程序会继续运行，避免崩溃。用于处理可能发生但不应该发生的错误。
  • 在编辑器中调试：在Visual Studio中，将调试器附加到Unreal Editor进程，就可以像调试普通程序一样设置断点、单步执行、查看变量。这是最强大的调试方式。
  • 使用DrawDebug系列函数：如上面的例子，DrawDebugLine,DrawDebugSphere等可以在游戏视口中临时绘制图形，非常适合调试移动、碰撞、射线检测等空间逻辑。

6.4 热重载（Live Coding）的注意事项

UE5支持修改C++代码后，在不关闭编辑器的情况下重新编译并加载，即热重载。这能极大提升迭代效率。

  • 什么情况下有效：修改函数体内的实现逻辑通常可以热重载。
  • 什么情况下无效或危险：
    • 修改头文件（添加/删除成员变量、函数，修改UCLASS/UPROPERTY宏等）。
    • 改变类的继承关系。
    • 添加或删除虚函数。
    • 在这些情况下，热重载可能失败，或者导致编辑器不稳定。最安全的做法是关闭编辑器，重新编译整个项目。

实操心得：养成好习惯：在准备进行可能破坏热重载的修改（尤其是头文件改动）之前，保存所有蓝图和场景，然后关闭编辑器进行编译。虽然多花一两分钟，但能避免许多诡异的内存错误和编辑器崩溃，从长远看节省了大量排查问题的时间。对于频繁迭代的函数逻辑，可以放心使用热重载来快速验证。

编程学习 学习日记 实战经验
← 返回列表