1
// ===== Epic 命名前缀：每一个字母背后都是技术约束 =====
2
//
3
// ┌────────┬──────────────────────┬──────────────────────────────────┐
4
// │ 前缀    │ 继承自                │ 关键特征                           │
5
// ├────────┼──────────────────────┼──────────────────────────────────┤
6
// │ U      │ UObject               │ GC 管理 / 反射 / 序列化 / 蓝图可见   │
7
// │ A      │ AActor → UObject      │ 可放入关卡 / 网络复制 / Tick        │
8
// │ F      │ 无（普通 C++ 类/结构体）│ 无 GC / 栈或堆分配 / 值语义          │
9
// │ I      │ 无（纯虚 C++ 接口）    │ 多重继承安全 / 必须用 UINTERFACE 配对 │
10
// │ E      │ uint8 枚举底层         │ UENUM 宏标记反射                   │
11
// │ T      │ 模板类                 │ TArray / TMap / TSharedPtr          │
12
// │ S      │ SWidget                │ Slate UI 控件                      │
13
// │ b      │ bool 变量               │ 布尔成员/局部变量——非类型前缀         │
14
// │ C      │ Concept（C++20）       │ 模板约束——UE5 中后期引入              │
15
// └────────┴──────────────────────┴──────────────────────────────────┘
16

17
// ---------- 前缀实战示例 ----------
18
// U —— UObject 子类
19
UCLASS()
20
class UMyObject : public UObject { /* ... */ };    // 可被 GC 追踪
21

22
// A —— AActor 子类（AActor 从 UObject 继承）
23
UCLASS()
24
class AMyActor : public AActor { /* ... */ };       // 可放入关卡
25

26
// F —— 普通结构体（不继承 UObject）
27
USTRUCT()
28
struct FMyStruct                             // 值类型——通常栈分配
29
{
30
    GENERATED_BODY()
31
    int32 Value;
32
};
33

34
// I —— 接口（纯虚 C++ 类）
35
class IMyInterface                            // 不加 UCLASS —— 这是原生 C++ 接口
36
{
37
public:
38
    virtual void DoSomething() = 0;
39
};
40

41
// E —— 枚举
42
UENUM()
43
enum class EMyState : uint8
44
{
45
    Idle, Running, Dead
46
};
47

48
// T —— 模板类
49
TArray<int32> Numbers;                        // 模板容器
50
TSharedPtr<FMyStruct> Ptr;                    // 智能指针
51

52
// S —— Slate 控件
53
class SMyButton : public SCompoundWidget { /* ... */ };
54

55
// b —— 布尔变量（注意：这是变量前缀，不是类型前缀）
56
bool bIsAlive = true;
57
bool bHasWeapon = false;

1
// ===== 为什么 U / A / F 的区分如此重要？ =====
2
//
3
// 面试高频考点："UObject 和 F 开头的结构体有什么区别？"
4
//
5
// UObject（U 前缀）：
6
//   ✓ 由 GC 自动管理生命周期——你不需要手动 delete
7
//   ✓ 拥有反射数据——UFUNCTION / UPROPERTY 可被蓝图访问
8
//   ✓ 支持序列化——SaveGame / 网络复制
9
//   ✓ 必须通过 NewObject<T>() 创建——不能用 new
10
//   ✓ 使用 IsValid() 判定存活——现代 UE5 已彻底移除 IsPendingKill()
11
//   ✗ 创建和销毁开销大——GC 扫描 + 反射元数据
12
//
13
// AActor（A 前缀）：
14
//   ✓ 继承 UObject 的所有特性
15
//   ✓ 可通过 SpawnActor<T>() 放入关卡世界
16
//   ✓ 支持 Tick / BeginPlay / EndPlay 生命周期
17
//   ✓ 支持网络复制（RPC / 属性同步）
18
//   ✗ 比普通 UObject 更重——Actor 注册 + 世界管理
19
//
20
// 普通结构体（F 前缀）：
21
//   ✓ 零反射开销——纯 C++ 性能
22
//   ✓ 可栈分配——创建销毁极快
23
//   ✓ 可在 USTRUCT 宏标记后获得有限反射（序列化/蓝图暴露）
24
//   ✗ 没有 GC——必须手动管理生命周期（或用 TSharedPtr）
25
//   ✗ 不支持网络复制（除非包装在 UObject 的 UPROPERTY 中）
26
//
27
// 经验法则：
28
//   "如果数据需要被 GC 追踪、蓝图访问、或网络复制 → U 前缀（UObject）
29
//    如果只是纯数据载体，在函数间传递 → F 前缀（普通结构体）
30
//    如果需要出现在关卡世界中 → A 前缀（AActor）"
31

32
// ---------- 命名前缀编译强制执行 ----------
33
//
34
// UE 的命名前缀不是"建议"——UBT 在编译时会检查：
35
//   - UObject 子类必须以 U 开头 → 否则编译警告
36
//   - AActor 子类必须以 A 开头 → 否则编译警告
37
//   - UEnum 必须以 E 开头 → 否则编译警告
38
//   - 布尔变量以 b 开头 → 部分检查（编辑器 lint）
39
//
40
// 可通过 .Build.cs 中 bEnforceIWYU = true 启用更严格的前缀检查

1
// ===== 三大禁用特性：不是随意选择，是硬件级工程原因 =====
2
//
3
// ① C++ 异常（Execeptions）—— 默认关闭
4
//
5
// 原因：
6
//   - 二进制体积：异常处理表（EH Tables）使每个函数的代码膨胀 15%~30%
7
//   - 性能：即使不 throw，异常处理框架也有 ~3% 的运行时开销
8
//   - 跨平台一致：游戏主机（Console）编译器对异常的支持不完全一致
9
//   - 确定性：异常展开栈的过程在实时游戏循环中不可预测
10
//
11
// UE 替代方案：返回值 + 错误码 + check/ensure
12
//   函数返回 bool 表示成功/失败
13
//   关键路径用 check() 崩溃（开发期立即定位问题）
14
//   非关键路径用 ensure() 记录警告（不崩溃，收集数据）
15

16
// ② RTTI（Run-Time Type Information）—— 默认关闭
17
//
18
// 原因：
19
//   - 内存开销：每个多态类型维护一个 type_info 结构
20
//   - dynamic_cast 开销：遍历继承链的字符串比较
21
//   - UE 有更好的替代方案：UHT 反射数据比 RTTI 更丰富
22
//
23
// UE 替代方案：
24
//   Cast<T>(UObject*) —— 利用 UHT 生成的反射数据做类型检查
25
//     比 dynamic_cast 快 10~20 倍——使用整数 ID 而非字符串比较
26
//   IsA(UClass*) —— 运行时判断类型
27
//   StaticClass() —— 获取 UClass（替代 typeid）
28

29
// ③ STL 不在模块公共 API 中暴露
30
//
31
// 原因：
32
//   - ABI 兼容性：不同平台的 STL 实现不同——暴露 STL 类型到 API 边界
33
//     意味着你的 DLL 和调用方的 STL 实现必须完全一致
34
//   - 内存控制：UE 有自定义分配器——STL 的 new/delete 绕过 GMalloc
35
//   - 命名风险：std::vector<bool> 的特化行为与常规容器完全不同
36
//
37
// UE 替代方案：
38
//   std::vector<T>     → TArray<T>
39
//   std::map<K,V>       → TMap<K,V>
40
//   std::set<T>         → TSet<T>
41
//   std::string         → FString / FName / FText
42
//   std::shared_ptr<T>  → TSharedPtr<T>（仅用于非 UObject）
43
//   std::function<…>    → TFunction<…> 或 UE 委托
44

45
// ---------- 正确写法 vs 错误写法 ----------
46
// ✗ 在公共 API 中使用 STL
47
class BAD_API FMyPublicClass
48
{
49
public:
50
    std::vector<int> GetValues() const;   // ✗ STL 在 API 边界
51
    std::string GetName() const;          // ✗ std::string
52
};
53

54
// ✓ 使用 UE 等价类型
55
class GOOD_API FMyPublicClass
56
{
57
public:
58
    TArray<int32> GetValues() const;       // ✓ TArray
59
    FString GetName() const;              // ✓ FString
60
};
61

62
// ✓ STL 在内部实现中使用是可以的
63
void FMyPublicClass::InternalHelper()
64
{
65
    std::unordered_map<int, float> LookupTable;  // ✓ 内部使用 OK
66
}

1
// ===== new / delete 的使用边界 =====
2
//
3
// UObject 子类：绝对不能用 new / delete
4
//   → 必须用 NewObject<T>() 创建
5
//   → 由 GC 自动销毁——不要手动 delete
6
//
7
// 非 UObject（F 前缀类）：可以使用 new / delete
8
//   → 但推荐 UE 分配器（GMalloc 系列）
9
//   → 或使用智能指针（TSharedPtr / TUniquePtr）
10
//
11
// 数组分配：使用 UE 内存函数
12
//   → FMemory::Malloc / FMemory::Free
13
//   → 或直接使用 TArray（推荐——自动管理内存）
14

15
// ---------- 正确写法 vs 错误写法 ----------
16
// ✗ 对 UObject 使用 new
17
UMyObject* Bad1 = new UMyObject();            // ✗ 绕过 GC——永远不会被回收
18
delete Bad1;                                   // ✗ GC 可能仍持有引用→二次释放崩溃
19

20
// ✓ 使用 NewObject
21
UMyObject* Good1 = NewObject<UMyObject>();     // ✓ GC 追踪，自动回收
22

23
// ✗ 对 Actor 使用 new
24
AMyActor* Bad2 = new AMyActor();              // ✗ 不在世界管理范围内
25

26
// ✓ 使用 SpawnActor
27
AMyActor* Good2 = GetWorld()->SpawnActor<AMyActor>();  // ✓ 世界管理生命周期

1
// ===== 错误处理分层：开发期崩溃 vs Shipping 零开销 vs 运行期监控 =====
2
//
3
// ┌──────────┬────────────────────┬──────────────────┬──────────────────┐
4
// │ 断言类型   │ 行为                 │ Shipping 包行为    │ 使用场景           │
5
// ├──────────┼────────────────────┼──────────────────┼──────────────────┤
6
// │ check    │ 条件为 false → 崩溃   │ 表达式+崩溃代码蒸发 │ "绝不应该发生"      │
7
// │ checkf   │ check + 格式化消息    │ 同上               │ 需要上下文信息的崩溃  │
8
// │ verify   │ 同 check             │ 表达式依然执行，     │ "函数调用必须发生"   │
9
// │          │                      │ 但崩溃代码蒸发       │ （如返回值的函数）    │
10
// │ verifyf  │ verify + 格式化消息   │ 同上               │ verify + 上下文     │
11
// │ ensure   │ 首次 false → 日志+    │ ★ 默认 Shipping(DO_CHECK=0) │ "不该发生但别崩"     │
12
// │          │ Callstack，不崩溃     │ 表达式退化为裸求值——    │ （Dev 期收集 Bug 数据）│
13
// │          │                      │ 无日志/无栈/零开销      │                      │
14
// │ ensureMsgf│ ensure + 格式化消息   │ 同上——仅 Dev/Debug 有效 │ ensure + 上下文       │
15
// │ ensureAlways│ 每次都记日志+栈      │ 同上——仅 Dev/Debug 有效 │ 高频路径监控（Dev 期）  │
16
// └──────────┴────────────────────┴──────────────────┴──────────────────┘
17

18
// ---------- check：致命断言——"这不应该发生，发生了就崩" ----------
19
void CheckExamples(AActor* Actor)
20
{
21
    // 基础 check
22
    check(Actor != nullptr);             // Actor 为空 → 立即崩溃
23
    check(Actor->IsValidLowLevel());     // 检查 UObject 底层内存是否有效
24

25
    // checkf：带格式化消息
26
    checkf(Actor->GetWorld(), TEXT("Actor %s has no World!"), *Actor->GetName());
27

28
    // checkNoEntry：标记"永远不该执行到这里"的代码路径
29
    switch (State)
30
    {
31
        case EState::Idle:    HandleIdle(); return;
32
        case EState::Running: HandleRunning(); return;
33
        default:
34
            checkNoEntry();              // 未知状态 → 崩溃！
35
    }
36

37
    // unimplemented：标记"还未实现"的虚函数调用
38
    // 等价于 checkf(false, TEXT("Function not implemented"))
39
}
40

41
// ---------- verify：保障表达式求值（函数有副作用或返回值时使用） ----------
42
void VerifyExamples()
43
{
44
    // verify：表达式在 Shipping 中也会执行
45
    // 区别：check(expr) —— Shipping 中 expr 和崩溃代码都蒸发
46
    //       verify(expr) —— Shipping 中 expr 依然执行，只有崩溃蒸发
47
    verify(GEngine != nullptr);          // 获取引擎单例——获取操作必须发生
48

49
    // 典型场景：函数返回值被用于错误检查
50
    int32 Result = SomeFunctionThatMustRun();
51
    verify(Result >= 0);                 // SomeFunctionThatMustRun 在 Shipping 中也执行
52

53
    // verifyf：带消息
54
    verifyf(World != nullptr, TEXT("World is null during initialization"));
55
}
56

57
// ensure：软警告——"不正常但不要死" ----------
58
void EnsureExamples(AActor* Actor)
59
{
60
    // ensure：仅在 Development/Debug 中首次失败时记录日志 + 调用栈，不崩溃
61
    // ★ 标准 Shipping（DO_CHECK=0）下：ensure 被预处理器彻底剥离——
62
    //   展开为裸表达式求值 (expr)，无日志、无栈、无分支检查——完全零开销。
63
    //   如果在 Shipping 中也需要 ensure，必须在 .Target.cs 中显式设置
64
    //   bUseLoggingInShipping = true 并手动启用 DO_CHECK。
65
    if (!ensure(Actor != nullptr))
66
    {
67
        return;  // 优雅降级——继续执行但跳过该逻辑（仅 Dev/Debug 生效）
68
    }
69

70
    // ensureMsgf：带消息
71
    ensureMsgf(Actor->GetComponentByClass<UPrimitiveComponent>(),
72
        TEXT("Actor %s has no collision component!"), *Actor->GetName());
73

74
    // ensureAlways：每次都记录（即使是第 100 次触发）
75
    // 使用场景：高频路径上的监控——需要统计发生次数
76
    ensureAlways(Actor->GetVelocity().Size() < MaxSpeed);
77
}
78

79
// ---------- Shipping 包中的行为差异（面试高频考点） ----------
80
//
81
// check()     → Dev/Debug：崩溃并打印消息。
82
//               Shipping：表达式和崩溃代码都蒸发——零 CPU 开销。
83
//
84
// verify()    → Dev/Debug：同 check。
85
//               Shipping：表达式依然执行（因为可能有副作用），但崩溃代码蒸发。
86
//
87
// ensure()    → Dev/Debug：首次失败记日志+栈，不崩溃。
88
//               默认 Shipping（DO_CHECK=0）：表达式被预处理器展开为裸求值——
89
//               ★ 没有日志、没有栈、没有检查逻辑——彻底零开销。
90
//               如果你需要在 Shipping 中保留 ensure → 在 .Target.cs 中设置
91
//               bUseLoggingInShipping = true 且手动启用 DO_CHECK。
92
//
93
// 面试标准答案：
94
//   "check 是'绝不应该发生'——开发期帮你立即定位 Bug，Shipping 零开销。
95
//    verify 是'这个函数调用必须发生'——即使 Shipping 也要执行表达式。
96
//    ensure 是'不正常但别崩'——但仅在非 Shipping（或手动启用 DO_CHECK）时有效。
97
//    默认 Shipping 中 ensure 被完全抹除——不能依赖它收集线上数据。"

1
// ===== 什么时候用哪个断言？决策树 =====
2
//
3
// 问题 1：这个条件失败后，继续执行会导致更严重的问题吗？
4
//   YES → check() 或 verify()
5
//     → 继续执行可能导致数据损坏、崩溃、安全漏洞
6
//   NO  → ensure()
7
//     → 跳过这个功能不影响核心逻辑
8
//
9
// 问题 2：条件表达式中的函数调用是否有副作用（必须执行）？
10
//   YES → verify()  —— 表达式在 Shipping 中也执行
11
//   NO  → check()   —— 表达式可在 Shipping 中蒸发
12
//
13
// 问题 3：这是高频路径吗？需要统计失败频率？
14
//   YES → ensureAlways()  —— 每次都记录
15
//   NO  → ensure()         —— 首次记录即可
16
//
17
// 实战决策示例：
18
//
19
//   check(GEngine)               → 引擎单例——为空后续一切不可用
20
//   check(Actor->GetWorld())     → World 为空意味着 Actor 不在世界中——继续无意义
21
//   verify(ModuleLoaded)         → 模块加载函数必须被调用（副作用）
22
//   ensure(!bIsInInvalidState)   → 状态异常但可以跳过当前 Tick 继续
23
//   ensureAlways(Speed < Max)    → 需要统计超速频率以定位性能 Bug

1
// ===== UE 类型转换体系：比标准 C++ 更安全、更快 =====
2
//
3
// ┌──────────────┬──────────────────────┬──────────────┬──────────────────┐
4
// │ 转换方式       │ 适用对象               │ 失败行为       │ 运行时开销         │
5
// ├──────────────┼──────────────────────┼──────────────┼──────────────────┤
6
// │ Cast<T>       │ UObject 子类           │ 返回 nullptr  │ 中等——反射 ID 比较  │
7
// │ StaticCast<T>  │ 任何类型               │ 编译期保证     │ 零（编译期）        │
8
// │ CastChecked<T> │ UObject 子类           │ 失败断言崩溃   │ 开发期：同 Cast    │
9
// │               │                       │              │ Shipping：同Static │
10
// │ DynamicCast<T>│ 需要 RTTI 的多态类型    │ 返回 nullptr  │ 高——字符串比较      │
11
// └──────────────┴──────────────────────┴──────────────┴──────────────────┘
12

13
void CastExamples(AActor* UnknownActor)
14
{
15
    // ---------- ① Cast<T>：UObject 安全转换（最常用） ----------
16
    // 利用 UHT 生成的反射数据——比 dynamic_cast 快 10~20 倍
17
    if (APawn* Pawn = Cast<APawn>(UnknownActor))
18
    {
19
        // 转换成功——安全使用 Pawn 特有的 API
20
        AController* Controller = Pawn->GetController();
21
        Pawn->GetMovementComponent()->Velocity;
22
    }
23
    else
24
    {
25
        // 不是 Pawn——优雅处理
26
    }
27

28
    // 连锁 Cast——一次检测多个类型
29
    if (ACharacter* Character = Cast<ACharacter>(UnknownActor))
30
    {
31
        Character->LaunchCharacter(FVector(0, 0, 500), false, false);
32
    }
33
    else if (APawn* Pawn = Cast<APawn>(UnknownActor))
34
    {
35
        // Character 继承 Pawn——先检测子类，再检测父类
36
        Pawn->GetController();
37
    }
38

39
    // ---------- ② StaticCast<T>：标准 static_cast 的 UE 封装 ----------
40
    // 无运行时开销——适用非 UObject 类型间的转换（编译期确定）
41
    float FloatValue = 3.14f;
42
    int32 IntValue = StaticCast<int32>(FloatValue);      // 等价于 (int32)FloatValue
43

44
    // 父类指针→子类指针——你确定类型正确
45
    APawn* DefinitelyPawn = StaticCast<APawn>(UnknownActor);
46
    // ⚠️ 如果 UnknownActor 不是 Pawn → 未定义行为！只在 100% 确定时使用
47

48
    // ---------- ③ CastChecked<T>：开发期类型断言 ----------
49
    // Development/Debug 构建中：行为同 Cast<T>——检查类型，失败则触发 check 断言崩溃
50
    // Shipping 构建中：退化为 StaticCast<T>——零开销，信任类型正确
51
    APawn* PawnCheck = CastChecked<APawn>(UnknownActor);
52
    // 适用于：你确定类型正确，但想在开发期捕捉意外情况
53

54
    // ---------- ④ 标准 dynamic_cast：不推荐 ----------
55
    // ⚠️ UE 默认禁用 RTTI——不能用于 UObject 类型
56
    // 只能用于启用了 RTTI 的非 UObject 类（极少见）
57
    // APawn* PawnDyn = dynamic_cast<APawn*>(UnknownActor);  // ✗ 编译错误——RTTI 禁用
58
}
59

60
// ---------- Cast 的底层原理（面试深度追问） ----------
61
//
62
// 为什么 Cast<T> 比 dynamic_cast 快得多？
63
//
64
// dynamic_cast：
65
//   遍历完整的继承链 → 做字符串比较（type_info::name()）
66
//   → 字符串操作 + 多次比较 = 慢
67
//
68
// Cast<T>：
69
//   ① 获取转换目标的 UClass* 静态反射对象（每个 UObject 子类有全局唯一的整数 ID）
70
//   ② 调用 IsA(TargetClass) → 用整数 ID 比较而非字符串
71
//   ③ 整数比较 ≈ 1~2 条 CPU 指令 vs 字符串比较 ≈ 数十条 + 内存访问
72
//
73
// 结论：Cast<T> 利用 UHT 预生成的反射元数据（编译期已知）替代运行时 RTTI 查询

1
// ===== Cast 的三种经典使用模式 =====
2

3
// ---------- 模式 1：防御式 Cast（推荐） ----------
4
// 永远检查返回值——优雅处理类型不匹配
5
void DefensiveCast(AActor* Actor)
6
{
7
    if (ACharacter* Character = Cast<ACharacter>(Actor))
8
    {
9
        // ✓ 安全使用
10
        Character->Jump();
11
    }
12
    // 不是 Character → 什么都不做，不崩溃
13
}
14

15
// ---------- 模式 2：断言式 Cast ----------
16
// 类型必须匹配——否则是代码逻辑 Bug
17
void AssertCast(AActor* Actor)
18
{
19
    ACharacter* Character = Cast<ACharacter>(Actor);
20
    check(Character);  // 不是 Character → 崩溃——这是 Bug，必须修复
21
    Character->Jump();
22
}
23

24
// ---------- 模式 3：接口查询 Cast ----------
25
void InterfaceCast(AActor* Actor)
26
{
27
    // UE 接口也通过 Cast 查询——利用 UHT 反射
28
    if (Cast<IInventoryInterface>(Actor))
29
    {
30
        // ★ BlueprintNativeEvent / BlueprintImplementableEvent 不能通过接口指针直接调用
31
        //    必须使用 UHT 生成的 Execute_ 前缀静态包装器
32
        IInventoryInterface::Execute_AddItem(Actor, Item);
33
    }
34

35
    // 注意：Cast<IXXX> 返回的是指针——用于类型检查
36
    //      调用接口方法必须用 Execute_{FunctionName}(UObject*, ...)
37
}
38

39
// ---------- 注意：Cast<T> vs IsA<T> ----------
40
void CastVsIsA(AActor* Actor)
41
{
42
    // Cast<T>：检查 + 转换——一步完成
43
    if (APawn* Pawn = Cast<APawn>(Actor)) { /* ... */ }
44

45
    // IsA<T>：仅检查类型——不返回转换后的指针
46
    if (Actor->IsA<APawn>())  // 返回 bool
47
    {
48
        // 需要再手动 Cast 或 StaticCast 才能使用 Pawn 的成员
49
        APawn* Pawn = StaticCast<APawn>(Actor);
50
    }
51

52
    // 经验法则：需要转换后的指针 → Cast<T>
53
    //           只需要判断类型   → IsA<T> —— 稍微快一点（不生成转换代码）
54
}

1
// ===== UE 接口：两个类一个概念 =====
2
//
3
// UE 的接口系统比标准 C++ 多一层——UHT 需要一个 UObject 包装类：
4
//
5
//   UMyInterface（UObject 包装）→ 为 UHT 提供反射锚点
6
//   IMyInterface（C++ 纯虚接口）→ 实际的 C++ 抽象类
7
//
8
// 这两者通过 UINTERFACE 宏绑定——名字只有前缀不同（U vs I）
9

10
// ---------- 完整的 UE 接口定义 ----------
11

12
// ① UObject 包装——为反射系统提供元数据
13
UINTERFACE(BlueprintType)
14
class UInventoryInterface : public UInterface
15
{
16
    GENERATED_BODY()
17
};
18

19
// ② C++ 实际接口——定义纯虚函数
20
class IInventoryInterface
21
{
22
    GENERATED_BODY()
23

24
public:
25
    // BlueprintNativeEvent：C++ 提供默认实现，蓝图可覆盖
26
    UFUNCTION(BlueprintNativeEvent, BlueprintCallable, Category = "Inventory")
27
    bool AddItem(const FName& ItemId);
28

29
    // BlueprintImplementableEvent：仅蓝图实现——C++ 不提供默认
30
    UFUNCTION(BlueprintImplementableEvent, BlueprintCallable, Category = "Inventory")
31
    void OnItemAdded(const FName& ItemId);
32

33
    // 纯 C++ 函数——蓝图不可见
34
    virtual int32 GetItemCount() const = 0;
35

36
    // ★ 接口不能有成员变量——只有纯虚函数
37
};
38

39
// ---------- 实现接口的类 ----------
40
UCLASS()
41
class AMyInventoryActor : public AActor, public IInventoryInterface
42
{
43
    GENERATED_BODY()
44

45
public:
46
    // 实现 BlueprintNativeEvent 的 C++ 默认版本
47
    // 注意函数名：AddItem → AddItem_Implementation
48
    virtual bool AddItem_Implementation(const FName& ItemId) override
49
    {
50
        Items.Add(ItemId);
51
        return true;
52
    }
53

54
    // 实现纯 C++ 接口函数
55
    virtual int32 GetItemCount() const override
56
    {
57
        return Items.Num();
58
    }
59

60
private:
61
    TArray<FName> Items;
62
};
63

64
// ===== 接口函数类型速查 =====
65
//
66
// BlueprintNativeEvent：
67
//   C++ 提供默认实现 → 蓝图可覆盖
68
//   实现函数名：{FunctionName}_Implementation
69
//   调用：直接调用 FunctionName()——引擎自动路由到蓝图或 C++ 实现
70
//
71
// BlueprintImplementableEvent：
72
//   仅蓝图实现——C++ 不提供函数体
73
//   在 .cpp 中不需要写 _Implementation 函数
74
//
75
// 纯 C++ virtual：
76
//   不加 UFUNCTION——纯 C++ 接口方法
77
//   蓝图不可见

1
// ===== UE 多重继承：仅接口安全 =====
2
//
3
// UE 允许的多重继承：
4
//   ✓ 一个 UObject/AActor 父类 + 多个 IXXX 接口
5
//   ✓ 接口可以多重继承接口
6
//
7
// UE 禁止的多重继承：
8
//   ✗ 两个 UObject 子类作为父类 → UHT 不支持，编译错误
9
//   ✗ 菱形继承（两个父类有共同祖先 UObject） → 编译错误
10
//
11
// 原因：UHT 生成的反射代码假设单继承链——多重非接口继承会破坏反射元数据
12

13
// ---------- 正确 vs 错误 ----------
14

15
// ✓ 一个 Actor 父类 + 多个接口
16
UCLASS()
17
class AMyCharacter : public ACharacter,                      // 单继承 AActor 链
18
                     public IDamageable,                      // 接口 1
19
                     public IInventoryInterface,              // 接口 2
20
                     public IInteractable                     // 接口 3
21
{
22
    GENERATED_BODY()
23
    // ...
24
};
25

26
// ✓ 接口继承接口
27
class IAdvancedInventory : public IInventoryInterface
28
{
29
public:
30
    virtual void SortItems() = 0;
31
};
32

33
// ✗ 两个 UObject 子类混用
34
// class ABadClass : public AActor, public UMyObject  // ✗ 编译错误！
35
// { ... };
36

37
// ✗ 菱形继承（两个父类都继承自同一个 UObject 子类）
38
// class ABadClass : public ACharacter, public APawn  // ✗ ACharacter 已继承 APawn！
39
// { ... };

1
// ===== 陷阱 #1：对 UObject 使用 new / delete =====
2
void BadMemoryManagement()
3
{
4
    // ✗ UObject 绕过 GC——永远不会被回收
5
    UMyObject* Obj = new UMyObject();
6
    delete Obj;  // GC 可能仍持有引用 → 二次释放崩溃
7
}
8
// ✓ NewObject<T>() + 让 GC 管理
9

10
// ===== 陷阱 #2：check 和 ensure 用反了 =====
11
void BadAssertUsage(AActor* Actor)
12
{
13
    // ✗ 用 ensure 保护必然条件——引擎单例为空意味着后续 100% 崩溃
14
    ensure(GEngine);  // 应该用 check——引擎基础服务不存在已经没有继续的意义
15
    GEngine->AddOnScreenDebugMessage(...);  // 如果 GEngine 为空→依然崩溃
16

17
    // ✗ 用 check 保护可选功能——物品不存在不应该让游戏崩溃
18
    check(Item != nullptr);  // 应该用 ensure——物品数据缺失可以跳过，不应崩溃
19
    Item->Use();             // 如果 check 触发 → 整个游戏崩溃
20
}
21
// ✓ 必然条件用 check，可选功能用 ensure
22

23
// ===== 陷阱 #3：Cast<T> 不检查返回值 =====
24
void BadCast(AActor* Actor)
25
{
26
    // ✗ Cast 可能返回 nullptr——直接解引用 → 崩溃
27
    APawn* Pawn = Cast<APawn>(Actor);
28
    Pawn->GetController();  // 如果 Actor 不是 Pawn → 空指针崩溃
29
}
30
// ✓ 总是检查 Cast 返回值
31

32
// ===== 陷阱 #4：用 dynamic_cast 替代 Cast<T> =====
33
void BadDynamicCast(UObject* Obj)
34
{
35
    // ✗ dynamic_cast 需要 RTTI —— UE 默认禁用
36
    //    即使手动启用了 RTTI —— 比 Cast<T> 慢 10~20 倍
37
    // AActor* Actor = dynamic_cast<AActor*>(Obj);  // 编译错误或极慢
38
}
39
// ✓ 始终用 Cast<T> 做 UObject 类型转换
40

41
// ===== 陷阱 #5：接口实现函数名写错 =====
42
// ✗ BlueprintNativeEvent 的实现函数必须命名为 {FunctionName}_Implementation
43
//    写成别的名字 → 链接器报 "unresolved external symbol"
44
class BAD_IMPLEMENTATION : public IMyInterface
45
{
46
    // ✗ 写了 AddItem 而不是 AddItem_Implementation
47
    virtual bool AddItem(const FName& ItemId) override;  // 链接错误！
48
};
49
// ✓ virtual bool AddItem_Implementation(const FName& ItemId) override;
50

51
// ===== 陷阱 #6：在 Shipping 构建中依赖 ensure 来收集数据 =====
52
void BadShippingBehavior()
53
{
54
    // ✗ 默认 Shipping（DO_CHECK=0）中 ensure 被完全抹除——表达式变为裸求值
55
    //    无日志、无栈、无崩溃——不能依赖它做任何追踪或收集
56
    //    ImportantSideEffect() 仍在 Shipping 中执行（表达式被保留为裸求值）
57
    ensure(ImportantSideEffect());
58
    // ★ 但日志和栈信息在 Shipping 中完全不存在——不要靠 ensure 做线上追踪
59
}
60
// ✓ 用专门的遥测系统（Analytics / Crash Reporter）替代 ensure 做 Shipping 数据收集

1
Q: "UE 的命名前缀（U/A/F/I/E/T/S/b）分别代表什么？为什么要这么严格？"
2
A: U = UObject（GC + 反射 + 序列化），A = AActor（关卡可见 + 网络复制），
3
   F = 普通结构体（纯 C++ 无 GC），I = 接口（纯虚、多重继承安全），
4
   E = 枚举，T = 模板类，S = Slate 控件，b = 布尔变量。
5
   严格性的原因：① 一看前缀就知道内存模型（栈 vs GC 堆？需不需要 IsValid？）；
6
   ② UBT 编译期检查——以 U 开头的类必须是 UObject 子类否则警告；
7
   ③ 团队效率——新成员不需要查继承链就知道怎么用。
8

9
Q: "check、verify、ensure 的区别？Shipping 包中怎么变化？"
10
A: check —— 致命断言，条件失败立即崩溃，Shipping 中表达式和崩溃代码都蒸发（零开销）。
11
   verify —— 同 check，但表达式在 Shipping 中也会执行（因为有副作用的函数调用需要求值）。
12
   ensure —— 软警告，仅在 Dev/Debug 中记录日志+栈，不崩溃。
13
   ★ 默认 Shipping（DO_CHECK=0）中 ensure 被预处理器完全抹除——无日志、无栈、无检查。
14
   关键区别：check = "Bug——崩"，verify = "副作用必须发生"，ensure = "Dev 期监控——Shipping 不存在"。
15
   一句话：check 是"代码 BUG"，verify 是"必须发生的副作用"，ensure 是"意外但可以继续"。
16

17
Q: "Cast<T> 和 dynamic_cast 的区别？为什么 UE 用 Cast？"
18
A: ① Cast<T> 利用 UHT 生成的反射数据（整数 ID 比较），dynamic_cast 依赖 RTTI（字符串比较）。
19
   ② Cast 比 dynamic_cast 快 10~20 倍——整数比较 vs 遍历继承链 + type_info::name() 字符串。
20
   ③ UE 默认关闭 RTTI——dynamic_cast 甚至无法编译用于 UObject。
21
   ④ Cast 返回 nullptr（安全），dynamic_cast 对指针同样返回 nullptr 但对引用抛异常（UE 不用异常）。