第2章 C++与UE编程核心

考点： 虚函数、vtable/vptr、动态绑定

参考答案：

1. 多态 = 同一操作作用于不同对象产生不同行为。C++ 的运行期多态通过虚函数实现；
2. 类中含虚函数时，编译器为该类生成一张虚函数表 vtable（静态数组，存放该类所有虚函数的地址），对象头部自动插入一个虚表指针 vptr 指向这张表；
3. 派生类继承基类的 vtable，重写某个虚函数时把对应表项替换为派生类版本；未重写的保留基类条目。通过基类指针/引用调用虚函数时，运行时按对象实际的 vptr 查表分发，即动态绑定；
4. 多重继承下对象含多个 vptr，指向多张 vtable；虚继承还会引入间接的 vbtable；
5. 代价：每个含虚函数的对象多一个 vptr（8 字节）+ 间接调用开销（编译器难以内联）。vtable 是类级共享的，vptr 是对象级的；
6. 易错：构造/析构期间 vptr 处于中间状态，调用虚函数不会分发到派生类版本（见 1.8）。

考点： 抽象类、虚析构、资源释放

参考答案：

1. 纯虚函数 virtual void Func() = 0; 所在类为抽象类，不可实例化，派生类必须实现全部纯虚函数（否则仍是抽象类）；
2. 通过基类指针 delete 派生类对象时，若析构不是虚函数，只会调用基类析构，派生类成员资源不会被释放 → 内存泄漏（严格说是未定义行为）；
3. 因此多态基类必须声明虚析构：virtual ~Base() = default;；
4. 析构设为 protected 可禁止栈对象和外部 delete，强制通过工厂/Release 接口释放，适合纯接口类；
5. UE 中：蓝图/引擎接口用 UINTERFACE/I*；被 UPROPERTY 管理的对象由 GC 负责，普通 C++ 类遵循虚析构规则。

考点： 重写检查、去虚化优化

参考答案：

1. override：显式声明重写基类虚函数，编译器会校验签名（参数、const、返回协变），写错直接编译报错，避免"本想重写却新声明了一个函数"；
2. final：放在虚函数后禁止派生类继续重写；放在类后禁止被继承。编译器可据此做去虚化（devirtualization），把虚调用优化为直接调用；
3. UE 实践：重写 BeginPlay/EndPlay 等生命周期函数务必加 override，配合编辑器检查可尽早发现签名不一致。

考点： 菱形继承、虚继承、UInterface

参考答案：

1. 菱形继承：B、C 都继承 A，D 又同时继承 B、C，则 D 中存在两份 A 的子对象：访问 A 的成员产生二义性，A 的构造函数被调用两次；
2. 解决方案：虚继承 class B : virtual public A，使 A 子对象只有一份；虚基类构造函数由最派生类负责调用（需在 D 的初始化列表构造 A）；
3. 代价：虚继承使对象布局复杂化（多一层间接），效率与内存都有额外开销；
4. UE 的规避：UObject 类不允许多重继承，接口通过 UINTERFACE（I 前缀）实现组合；普通 C++ 类也尽量用"组合优于继承"；
5. 面试要点：指出"接口多继承 + 实现单继承"是工程上的标准答案。

考点： 虚函数 vs 模板、CRTP、静态多态

参考答案：

1. 运行期多态：虚函数 + vtable，灵活、可在运行时扩展（插件/蓝图），代价是 vptr 内存与间接调用，无法内联；
2. 编译期多态：模板在编译期按类型生成代码，零虚开销、可内联，但类型必须编译期确定；
3. CRTP（奇异递归模板模式）：

template<class Derived>
class Base {
public:
    void Interface() { static_cast<Derived*>(this)->Impl(); }
};
class Child : public Base<Child> {
public:
    void Impl() { /* 子类实现 */ }
};

通过 static_cast 调用派生类方法，实现"接口复用 + 编译期分发"； 4. UE 例子：TSharedFromThis、FRunnable 相关的模板基类、TBaseUObject 等； 5. 取舍：固定类型、性能敏感路径用模板多态；需要运行时扩展用虚函数。

考点： 拷贝构造、拷贝赋值、对象切片

参考答案：

1. 浅拷贝：默认拷贝构造/赋值逐成员按位复制，指针成员只复制地址 → 两个对象共享同一块内存，析构时双重释放或悬垂；
2. 深拷贝：为指针成员分配新内存并复制内容，各自独立；
3. 遵循 Rule of Three：一旦自定义析构函数，就必须同时自定义拷贝构造与拷贝赋值（C++11 起扩展为 Rule of Five，见 2.1）；
4. 对象切片：按值传参/返回/赋值为基类时，派生类部分被"切掉"，只剩基类部分 → 丢失多态。应通过指针/引用/智能指针传递；
5. UE 实践：结构体默认值类型按值拷贝是安全的；涉及 UPROPERTY 引用注意所有权语义。

考点： static_cast、dynamic_cast、const_cast、reinterpret_cast、RTTI、Cast<>

参考答案：

1. static_cast：编译期、相关类型之间转换（基↔派生、数值类型），不检查运行时类型；
2. dynamic_cast：运行期安全向下转换，要求多态类型（含虚函数），失败返回 nullptr（指针）或抛 std::bad_cast（引用），依赖 RTTI，开销较大；
3. const_cast：增删 const 限定，滥用是未定义行为；
4. reinterpret_cast：位级重解释，最危险，仅用于底层场景；
5. UE Cast<T>(obj)：利用 UClass 反射链做类型检查（比对继承链），不依赖编译器 RTTI，性能优于 dynamic_cast、跨 DLL 可用，对 UClass 体系是首选；
6. 易错：Cast 失败返回 nullptr 必须判空；引用 dynamic_cast 失败抛异常，而 UE 禁用异常，避免在引用转换上使用（用 Cast 或先取类再比较）。

考点： 构造期 vptr、虚函数分发

参考答案：

1. 对象构造时 vptr 是逐步初始化的：基类构造期间 vptr 指向基类的 vtable，等派生类成员初始化后才指向派生类 vtable。因此在构造函数内调用虚函数会解析到当前正在构造的类的版本（基类构造时就是基类版本），调不到派生类覆盖；
2. 析构顺序相反：先执行派生类析构、vptr 已切回基类表，此时调用虚函数同样解析到基类版本；
3. 若在基类构造函数里调用纯虚函数，则是未定义行为（可能崩溃）；
4. 正确做法：构造中调用自身类方法；把初始化逻辑放到派生类完全构造之后（如 UE 的 PostInitializeComponents/OnConstruction/BeginPlay）；
5. UE 例子：构造函数里用 CreateDefaultSubobject 创建组件是可以的，但不能在构造函数里 SpawnActor/调其他 Actor 接口。

考点： RAII、资源管理、拷贝规则

参考答案：

1. RAII（资源获取即初始化）：资源在构造函数获取、析构函数释放，随对象生命周期自动管理，天然异常安全；
2. Rule of Three：需要自定义析构、拷贝构造、拷贝赋值三者之一时，三者都应自定义（因为管理资源的方式一致）；
3. Rule of Five：C++11 起还要加上移动构造与移动赋值；
4. Rule of Zero：尽量使用智能指针、容器等 RAII 包装类，不手写资源管理代码；
5. UE 实践：UObject 由 GC 管理；普通 C++ 对象用 TUniquePtr/TSharedPtr + RAII；组件类遵循 Rule of Zero。

考点： 三种智能指针、所有权模型

参考答案：

1. unique_ptr：独占所有权，禁止拷贝、支持移动，零额外开销，最适合"所有权唯一"的对象（如工厂返回值、唯一管理的资源）；
2. shared_ptr：共享所有权，基于堆上控制块的引用计数，copy +1、析构 -1、归 0 释放对象；计数操作原子化（跨线程复制/析构安全，但对象本身仍需同步）；存在循环引用问题；
3. weak_ptr：不增加引用计数，用于观察或打破循环引用，使用时必须 lock() 提升为 shared_ptr 再访问；
4. 选择原则：能用 unique 就不用 shared；必须共享时用 weak 打破环；
5. 注意：make_shared 一次分配控制块+对象、异常安全；对象要在内部以 shared_ptr 返回 this 需继承 enable_shared_from_this（见 2.6）。

考点： UE 智能指针、引用计数

参考答案：

1. TSharedPtr<T>：与 std::shared_ptr 等价，引用计数线程安全（默认线程模型可用 ESPMode::ThreadSafe 指定）；注意计数安全 ≠ 对象访问安全；
2. TSharedRef<T>：非空保证，构造时必须绑定对象，解引用无需判空；语义上表示"必然存在"，适合函数参数与成员声明；
3. TWeakPtr<T>：弱引用，不增加计数，Pin() 提升为 TSharedPtr 判断对象是否存活；
4. TUniquePtr<T>：独占所有权，禁止拷贝、支持移动，用 MakeUnique 创建；
5. 转换：TSharedRef 可隐式转 TSharedPtr；TSharedPtr 转 TWeakPtr 直接转；TWeakPtr → TSharedPtr 用 Pin()；
6. 创建：MakeShared<T>()、MakeSharedFromThis<T>()；UObject 不能用智能指针管理，必须用 NewObject（见 2.5）。

考点： 引用计数、循环引用、TWeakPtr 破环

参考答案：

1. 原理：shared_ptr 在堆上分配控制块存引用计数；拷贝 +1、析构 -1、归 0 同时销毁对象与控制块；
2. 循环引用：A 持 shared_ptr<B>、B 持 shared_ptr<A>，两个计数都永不归零 → 泄漏；
3. 解决：把环中一侧改为 weak（TWeakPtr / std::weak_ptr），环中至少一侧不参与计数，环即可打破；
4. UE 典型场景：父子节点互相引用、双向链表、管理器与成员互持，用 TWeakObjectPtr/TWeakPtr 保存"父级/回指"；
5. 易错：shared_ptr 计数线程安全 ≠ 指向对象线程安全；UE 中 TSharedPtr 计数用原子操作，TWeakPtr 的 Pin 也有弱计数防 ABA。

考点： GC 与引用计数、TObjectPtr、TWeakObjectPtr

参考答案：

1. UObject 生命周期由 GC 标记-清除管理，GC 必须能发现所有指向它的强引用（可达性分析）。而 TSharedPtr 的引用计数对 GC 不可见，不会阻止 GC 回收对象，导致"引用还活着、对象已被回收"的悬垂，同时计数无法清零造成泄漏，是双重灾难；
2. 规则：强引用 UObject 必须通过 UPROPERTY（推荐 TObjectPtr<T>）让 GC 跟踪；非反射的普通 C++ 结构/类中只能使用弱引用 TWeakObjectPtr<T>（对象销毁时引用自动置空）或裸指针并严格管理生命周期；
3. 容器中引用 UObject：TArray<TObjectPtr<AActor>>（UCLASS 成员）或 TArray<TWeakObjectPtr<AActor>>（普通类）;
4. 结论：GC 对象用 UPROPERTY/TObjectPtr，非 GC 对象用 TSharedPtr/TUniquePtr——两者不能混用；
5. 面试加分：TObjectPtr 在编辑器下是惰性解析指针（可延迟加载/卸载），运行时等同普通指针。

考点： shared_from_this、控制块

参考答案：

1. 当对象在函数内部需要以 shared_ptr 返回 this（如把回调绑定到自身生命周期）时，类必须继承 TSharedFromThis<T>（C++ 侧为 std::enable_shared_from_this），并调用 AsShared() / shared_from_this()；
2. 前提条件：对象必须已由一个智能指针管理（构造时控制块已建立）。若对象只是栈上/裸 new 出来的，shared_from_this() 会崩溃或抛异常；
3. 避免重复持有：共享 this 会基于当前对象的控制块增加计数，不会创建第二份对象；
4. UE 用法：class FWorker : public TSharedFromThis<FWorker>；注意默认是非线程安全线程模型，跨线程共享要指定 ESPMode::ThreadSafe；
5. 局限：UObject 不适用（见 2.5），且不要在构造函数里调用 AsShared()（此时控制块尚未建立）。

考点： 弱引用、软引用、资源加载

参考答案：

1. TWeakObjectPtr<T>：UObject 的弱引用，不阻止 GC；对象被回收时引用自动置空，访问前需 IsValid() 或 Get() 判空；
2. TSoftObjectPtr<T>：软引用，内部只存对象路径字符串，不加载资源；调用 LoadSynchronous() 或异步加载才真正加载，用于按需加载、避免启动时全量加载；
3. TSoftClassPtr<T>：软引用类（保存 UClass 路径），LoadSynchronous() 得到 UClass；
4. 对比：硬引用（UPROPERTY 直接指针/TObjectPtr）会随加载强制加载被引用资源；软引用适合引用关系不紧密、资源大、非关键依赖的场景；
5. 常见组合：弱引用保引用不阻止回收、软引用延迟加载、硬引用保证常驻资源。

考点： 所有权设计、生命周期管理

参考答案：

1. 明确所有权：谁创建谁释放；观察者/引用者不转移所有权；
2. 裸指针只做观察者，不参与所有权；有所有权就用智能指针；
3. 容器中的指针：非 UObject 用 TArray<TSharedPtr<T>>/TArray<TUniquePtr<T>>；UObject 用 UPROPERTY TArray<TObjectPtr<T>> 或 TArray<TWeakObjectPtr<T>>；
4. 避免在回调/异步任务中捕获裸 this（用 TWeakPtr/TWeakObjectPtr + 判活提升，见 4.2）；
5. UE 惯例：跨对象长期引用用强引用或事件（delegate）；销毁时解除引用关系（RemoveFromRoot、delegate 解绑、容器清理）。

考点： 模板、全特化、偏特化

参考答案：

1. 模板是编译期生成代码的蓝本（实例化），支持函数模板、类模板、变量模板（C++14）；
2. 全特化：template<> void f<int>(...)，针对某个具体类型提供专门实现；
3. 偏特化：仅类模板支持，如 template<class T> class P<T*> {...} 对指针类型特化；函数模板不支持偏特化，可用重载或 if constexpr 替代；
4. 匹配优先级：全特化 > 偏特化 > 主模板；SFINAE 用于从候选集中剔除不合规版本；
5. 易错：模板声明与定义分离到 .cpp 会导致链接失败（模板必须在头文件内实现，或用显式实例化）；UE 中模板类全部写在 .h。

考点： SFINAE、替换失败、enable_if

参考答案：

1. SFINAE（Substitution Failure Is Not An Error，替换失败不是错误）：模板实例化时若替换导致无效表达式/类型，该候选从重载集中剔除而不是报错，编译继续尝试其他候选；
2. 用途：探测类型是否具备某成员/方法/运算符、按类型启用或禁用重载、约束模板参数；
3. 经典写法：decltype(std::declval<T>().method(), void()) 探测成员存在，配合 std::enable_if<B, T> 控制重载：

template<typename T>
auto HasFoo(int) -> decltype(std::declval<T>().Foo(), std::true_type{});
template<typename T> std::false_type HasFoo(...);

4. UE 例子：TIsDerivedFrom、TEnableIf、IsEnumClass 等类型萃取均基于此机制；
5. 易错：探测表达式必须出现在函数签名或模板参数中（不能只在函数体内），否则不触发 SFINAE；C++20 起用 Concepts 替代更清晰（见 3.6）。

考点： 参数包、折叠表达式

参考答案：

1. 可变参数模板：template<class... Args> void F(Args... args)，Args 为参数包，用 sizeof...(Args) 取个数；
2. 展开方式：旧式用递归（每次取头一个再递归调剩余）；C++17 引入折叠表达式简化：(args + ...)、(std::cout << ... << args)；
3. 应用：printf 类工具、tuple 实现、完美转发任意参数给构造函数/函数（配合 std::forward，见 4.4）；
4. UE 中：TFunction、TFunc、泛型工具大量使用参数包；Delegate 的 Execute 也支持任意参数；
5. 易错：一元左折叠处理空包时需要默认值（如 (args + ...) 空包无默认值编译失败）。

考点： traits、enable_if、编译期类型判断

参考答案：

1. <type_traits> 提供编译期类型判断与变换：is_same、is_base_of、is_convertible、is_integral、remove_reference、conditional 等；
2. enable_if<B, T>：条件 B 为真时提供成员 ::type = T，为假则无 ::type → 触发 SFINAE 剔除对应重载；
3. UE 对应物：TIsDerivedFrom<T, Base>、TIsPointer、IsArithmetic、TEnableIf、IF<B, C1, C2>（编译期三元选择类型）；
4. 用途：约束泛型算法、按类型区分实现（如容器是 TMap 还是 TArray 走不同逻辑）、性能优化分支；
5. 提示：C++20 起优先用 Concepts（可读性更好、报错友好），但 UE 大量代码仍用 enable_if 风格保持兼容。

考点： 编译期计算、模板递归、零运行时开销

参考答案：

1. 模板元编程：利用模板递归 + 特化在编译期完成计算（斐波那契、质数、类型选择），运行时零开销；
2. 关键技巧：递归模板实例化、偏特化做终止条件、using/static constexpr 提取结果；
3. 典型例子：

template<int N> struct Fib { static const int value = Fib<N-1>::value + Fib<N-2>::value; };
template<> struct Fib<0> { static const int value = 0; };
template<> struct Fib<1> { static const int value = 1; };

4. 优势：结果在编译期固定、无运行时分支；代价：编译时间激增、实例化膨胀、代码难读难调试；
5. UE 中：UHT 生成代码、容器 Traits、属性系统大量运用此类技巧；实践建议复杂逻辑用 constexpr 函数 + if constexpr 替代。

考点： concept、requires、约束模板

参考答案：

1. Concepts 为模板参数命名一组编译期约束，如：

template<typename T>
concept Integral = std::is_integral_v<T>;

template<Integral T> void F(T v);   // 约束写法

2. 也可用 requires 子句内联约束：template<typename T> requires std::is_integral_v<T> void F(T);；
3. 相比 SFINAE：可读性强、错误信息友好、约束可命名复用、可参与重载决议（约束更强的候选优先）；
4. 标准库 C++20 起算法/类型用 concept 约束；
5. UE5.3 起默认 C++20，可用 Concepts 约束模板类型；但为兼容老代码仍大量保留 enable_if。

考点： 编译期 if、丢弃分支

参考答案：

1. if constexpr (常量条件) { } else { }：条件在编译期求值，未选中的分支不参与实例化（分支被丢弃），其中的无效代码不会导致编译错误；
2. 用途：按类型参数生成不同实现，如"T 是指针则走 X，否则走 Y"，替代标签分发（tag dispatch）与部分 SFINAE 场景：

template<typename T>
void Clear(T& v) {
    if constexpr (std::is_pointer_v<T>) { v = nullptr; }
    else { v.clear(); }
}

3. 注意：两个分支都必须是语法合法的代码（只是不实例化/不参与重载决议），不能是纯语法错误；
4. 条件必须是编译期常量（constexpr 表达式或类型判断）。

考点： 实例化、代码膨胀、编译时间

参考答案：

1. 每遇到一组新的模板实参，编译器生成一份实例化代码 → 二进制膨胀（code bloat）与编译时间增长；
2. 缓解手段：
   • 提取不依赖模板参数的部分到非模板函数；
   • 用显式实例化（extern template / explicit instantiation）控制生成位置与数量；
   • 减少不必要的泛型嵌套（如多层容器模板）；
3. UE 现状：容器/智能指针模板定义必须放在头文件（前向声明模板无法跨编译单元实例化），所以 UE 大量模板实现位于 .h；
4. IWYU（Include What You Use）配合 UBT 依赖分析减少多余头文件与重编译（见 12.5）；
5. 调试手段：查看编译生成的 .obj 符号大小、-ftime-trace（Clang）定位耗时模板。

考点： 类型推导、引用折叠、悬垂

参考答案：

1. auto 按值推导：会丢弃引用与顶层 const（const T& 推导为 T）；
2. auto&/const auto& 保留引用语义；decltype(expr) 精确推导表达式类型（含引用与 const）；
3. decltype(auto) 完整保留声明式类型，用于完美转发函数的返回值（转发返回值按原类型返回）；
4. 陷阱：
   • 函数返回 const T& 时用 auto 接收会拷贝一份；
   • 返回引用（尤其局部变量引用）时用 auto& 接收会得到悬垂引用（见 6.7）；
   • auto* 只接受指针类型，auto 可推导出指针；
5. UE 实践：遍历容器常用 for (const auto& Item : Arr) 避免拷贝，但注意锁与迭代器失效问题（见 5.2、11.10）。

考点： lambda、捕获列表、闭包

参考答案：

1. 语法：[capture](params) -> returnType { body }，返回类型可自动推导；
2. 捕获方式：
   • [=] 按值捕获所有外部变量；
   • [&] 按引用捕获所有外部变量；
   • [this] 捕获 this 指针；
   • [x = expr] 初始化捕获（C++14，可移动/构造临时对象进闭包）；
3. 底层实现：lambda 被展开为匿名函数对象（闭包类），捕获变量成为其成员，operator() 是重载的调用运算符；
4. UE 使用场景：delegate 回调、Async/ParallelFor、算法（Sort 谓词）、Timer 等；
5. 易错：值捕获复制开销、引用捕获与捕获 this 的生命周期风险（见 4.2）；无捕获的 lambda 可隐式转为函数指针。

考点： 悬垂捕获、异步生命周期、弱引用判活

参考答案：

1. 问题：lambda 捕获 this 后在异步/延迟回调中执行，此时对象可能已被销毁 → 悬垂调用崩溃；捕获 [&] 的局部变量在离开作用域后同样失效；
2. 对策（非 UObject）：类继承 TSharedFromThis，捕获 TWeakPtr<T>，回调内 Pin() 判活后再使用；或捕获共享指针保持对象存活（需权衡生命周期）；
3. 对策（UObject）：捕获 TWeakObjectPtr<T>，回调内 Get() + IsValid() 校验再访问；
4. 涉及成员数据时建议捕获值的副本或显式需要的变量，减少整对象捕获的开销与风险；
5. 注意：Pin() 成功只能保证"这一刻还活着"，回调函数执行期间对象仍可能被销毁（临界区很小，一般可接受）；UE 的 Timer/网络回调/AsyncTask 尤其要遵守"先判活再访问"。

考点： 右值引用、移动构造、move

参考答案：

1. 右值引用 T&& 绑定临时对象（右值），配合移动构造/移动赋值实现资源转移（把指针等资源"交接"而非深拷贝），提升性能；
2. 移动后的源对象必须处于合法但未指定状态（可析构、可重新赋值，通常置空指针/清零长度）；
3. std::move(x) 本身不做移动，只是把左值强转为右值引用以"授权"移动；UE 对应 MoveTemp（语义相同，避免歧义）；
4. UE 惯例：函数参数用 T&& + MoveTemp 转移大对象（如 TArray、FString）减少拷贝；蓝图侧不受影响；
5. 易错：对 const 对象 move 会退化为拷贝；没有移动构造时自动退化为拷贝；移动后继续使用源对象内容未定义；STL/UE 容器 Emplace 就地构造避免拷贝。

考点： 万能引用、引用折叠、std::forward

参考答案：

1. 万能引用：template<class T> void F(T&& x) 中的 T&&（T 为推导类型参数时）不是右值引用，而是按实参值类别折叠：传入左值 → T = T&；传入右值 → T = T；
2. 引用折叠规则：T& + && = &；只有 && + && = &&；
3. 完美转发：std::forward<T>(x)（UE 用 Forward<T>）根据推导出的 T 保持实参原始的左右值属性传给下一层，避免不必要的拷贝或多余的移动：

template<class T>
void MakeAndCall(T&& arg) {
    Call(std::forward<T>(arg));   // 保持左值/右值原样传递
}

4. 应用：工厂函数（MakeUnique 底层）、delegate 绑定、容器 Emplace、UI 构建（Slate）；
5. 易错：在转发函数内用普通参数名直接传递会丢失值类别（总是按左值处理）；UFunction 参数不能是模板/万能引用；转发同时要保留 const。

考点： auto 推导、initializer_list

参考答案：

1. auto 按值推导：丢弃引用与顶层 const（const T& → T）；auto&/const auto& 保留引用；
2. 初始化列表：auto a{1} 推导为 int；auto a = {1, 2} 推导为 std::initializer_list<int>；
3. 用途：简化冗长类型（迭代器、lambda 参数）、模板代码；
4. 易错：auto 在 C++20 前不能用于函数参数（需模板）；auto* 只接受指针类型，auto 也接受指针；auto 无法推导引用需显式写 &；花括号列表多元素与单元素推导规则不同。

考点： 解包、TMap 遍历、tuple

参考答案：

1. C++17 语法：auto [a, b] = expr;，可从 pair/tuple/结构体（公开成员）解包；
2. 典型应用：遍历 TMap：

for (const auto& [Key, Value] : MyMap) { /* ... */ }

3. 引用语义：auto& [a, b] 或 const auto& [a, b] 才能避免拷贝并允许修改原值；
4. UE 支持：TPair/TTuple/TMap 元素可直接解包；
5. 易错：解包绑定的是变量，不产生新对象（引用/拷贝取决于修饰符）；结构化绑定变量不能用于 lambda 捕获列表（C++20 前）；对数组也可解包。

考点： 现代容器、类型安全、空值表达

参考答案：

1. std::optional<T>：包装"可能没有值"的返回，替代"返回 -1 / 空指针 / 约定值"；has_value()、value_or(def)；UE 对应 TOptional<T>；
2. std::variant<A,B,...>：类型安全的联合体（同一时刻只存一种类型），std::visit 访问；UE 对应 TVariant；
3. std::any：任意类型（类型擦除），运行时 any_cast 检查；UE5 有 TAny/FVariant；
4. 使用场景：数据表字段、反射属性存储、函数返回多种结果、配置项；
5. 易错：optional 不能直接存引用（用指针）；variant 无当前类型或访问错误类型会抛 std::bad_variant_access；any 的类型检查是运行时成本。

考点： constexpr、三路比较、协程

参考答案：

1. const：承诺"运行期不修改"，编译期不一定能求值；
2. constexpr：编译期可求值，变量/函数可声明 constexpr；constexpr 函数也可在运行期调用；C++20 增加 consteval（只允许编译期求值）与 constinit；
3. 三路比较运算符 <=>（spaceship，C++20）：一次比较生成全部六种关系运算符；UE 中仍普遍手写 operator==，因为反射/网络序列化需要；
4. 协程（C++20 coroutine）：co_await/co_yield 实现无回调异步，主要服务于网络库等；UE 不原生支持 C++20 协程，异步用 Async/TaskGraph/TFuture 模拟；
5. UE 实践：常量与数学库大量使用 constexpr；但 UCLASS 反射与 constexpr 不兼容（反射在运行时构建），UPROPERTY 不能是 constexpr。

考点： 容器选型、UE 容器

参考答案：

1. 对照关系：std::vector → TArray；std::map → TSortedMap；std::unordered_map → TMap；std::set → TSet；std::string → FString；std::string_view → FStringView；std::unique_ptr → TUniquePtr；std::shared_ptr → TSharedPtr；std::function → TFunction；
2. 原则：UE 项目代码用 UE 容器（支持反射 UPROPERTY、网络复制、序列化、内存统计、平台一致）；纯算法/工具库可用 STL；
3. 不要混用两类迭代器；不要在两套容器间隐式互转；
4. 常见误区：std::list 在 UE 中基本不用（缓存不友好），用 TArray 替代；UE 没有与 std::vector<bool> 对应的特殊优化，布尔数组用 TBitArray。

考点： 迭代器失效、遍历删除

参考答案：

1. vector/TArray：插入/删除会使其后的迭代器、指针、引用全部失效（可能 realloc）；map/set 删除只影响被删元素；
2. 安全删除：优先用 erase-remove 惯用法：V.erase(std::remove_if(begin, end, pred), end);（STL）；
3. UE 等价写法：反向循环删除 for (int32 i = Arr.Num()-1; i >= 0; --i) if (pred) Arr.RemoveAt(i); 或直接 Arr.RemoveAll(pred) / Arr.RemoveAllPredicate；
4. 陷阱：range-for 底层隐藏迭代器，循环体内修改容器即 UB；嵌套遍历中删除外层容器元素极危险；遍历 TMap 时哈希表重排会失效；
5. 注意 RemoveAll 谓词内不要再访问同一容器（可能已重排）。

考点： TArray 内存布局、扩容

参考答案：

1. TArray 内部是连续内存的元素数组 + Num()（元素个数）+ Max()（容量）；相比 std::vector 少了迭代器相关冗余，布局更紧凑；
2. 特性：连续内存、缓存友好、随机访问 O(1)、尾部插入平摊 O(1)、支持 Reserve 预分配与 Shrink 收缩；
3. 与 std::vector 差异：TArray 使用可替换的分配器（TDefaultAllocator/TInlineAllocator/TFixedAllocator），提供 Add/Emplace/Insert/RemoveAt/RemoveAll/Find/IndexOfByKey 等丰富 API，支持 MoveTemp 移动；内存对齐与统计走引擎内存池；
4. 易错：Add 拷贝 vs Emplace 就地构造；存类对象会深拷贝（大对象考虑 TSharedPtr）；GetData() 返回的指针在容器扩容后失效；
5. UE 习惯：小且频繁遍历用 TArray 首选；需要稳定地址/元素不移动用 TIndirectArray 或指针容器。

考点： TMap、开放寻址、GetTypeHash

参考答案：

1. TMap 是哈希表：底层由 TSparseArray（元素稀疏存储，删除不搬动元素）+ 一个开放寻址哈希索引数组组成，索引数组元素指向稀疏数组；
2. 冲突处理采用开放寻址（线性探测或再哈希），不是链式哈希；哈希冲突多时元素会挤在相邻槽位，导致探测链变长；
3. 键要求：类型必须提供 GetTypeHash(const T&) 与 operator==；内建类型（int/FName/FString）都有默认实现，自定义结构需自行提供；
4. 与 std::map（红黑树，O(log n)、有序）对比：TMap 平均 O(1)、无序；需要有序遍历用 TSortedMap；
5. 易错：遍历 TMap 时不应增删元素（迭代器/哈希表重排）；operator[] 对不存在的键会默认构造一个空值插入，只想读用 Find/FindRef；不要把指向 Map 元素的指针跨插入长期保存。

考点： TSet 底层、去重

参考答案：

1. TSet 实现与 TMap 高度相似，可理解为"只存键的 TMap"：同样是 TSparseArray + 开放寻址索引，TSet<T> 在内部复用 TMap 的布局（实际是 hash 集合）；
2. 因此哈希冲突处理、GetTypeHash/operator== 要求、遍历时增删的注意事项都与 TMap 相同；
3. 用途：去重、快速存在性判断（Contains O(1)）、集合运算（Union/Intersect/Difference）；
4. 特性：元素不可重复、无序；需要保持插入顺序用 TArray + Contains 判断，或用 TOrderedMap/有序容器；
5. 变体：TSet<T, bInRequiresSort>；排序集合用 TSortedMap；并集差集结果拷贝新集合，注意大集合拷贝开销。

考点： 容器选择、复杂度

参考答案：

1. TArray：需要顺序、随机访问、频繁遍历、重排序、数据量小——默认首选；
2. TMap：键值映射关系、按键 O(1) 查找——需要"根据 X 找到 Y"时用；
3. TSet：只关心"是否存在"/去重——不需要关联值；
4. 决策：需要顺序 + 查重 → TArray + 线性查找（数据小）或 TMap + 保持顺序的辅助数组；按键快速查询 → TMap；只判存在 → TSet；
5. 大数据量查找：TMap/TSet 远优于 TArray 的线性扫描；TArray 的优势是遍历和缓存局部性，数据量小且访问频繁时更快。

考点： 内存分配、分配器策略、内存池

参考答案：

1. TArray<T, TInlineAllocator<N>>：前 N 个元素放在对象内嵌的栈内存（随容器对象一起分配），不触发堆分配；超过 N 才切换到堆分配器；
2. TFixedAllocator<N>：固定容量（等同于定长数组），超出容量触发断言/编译期限制，不能扩容；
3. TDefaultAllocator：普通堆分配；
4. 底层：UE 的所有堆分配走引擎内存池（FMemory::Malloc，不同平台有不同实现），支持内存统计、对齐、Leak 检测；
5. 选型：高频创建销毁的小容器（如每帧临时数组、粒子小队列）用 TInlineAllocator 减少堆碎片与分配开销；注意 N 过大会让容器对象本身变大（如作为 USTRUCT 成员会撑大内存）。

考点： 混合排序、快排退化

参考答案：

1. Introsort（内省排序） = 快排 + 堆排 + 插入排序的混合：主体用快排；当递归深度超过阈值（约 2×log₂n）时切换堆排避免快排最坏 O(n²)；小规模子区间用插入排序（常数小）；
2. 复杂度：平均与最坏均为 O(n log n)；不稳定（基于快排）；
3. TArray::Sort 使用 Introsort；需要稳定排序用 StableSort（基于归并）；
4. 自定义谓词：提供 operator< 或谓词，谓词必须是严格弱序（a<b 与 b<a 不能同时成立），否则 UB；
5. 排序大数据前先 Reserve 避免扩容；结构体排序默认按内存序，通常需自定义比较。

考点： 队列、栈、稀疏数组

参考答案：

1. TQueue<T>：FIFO 队列，Enqueue/Dequeue，常用于任务、事件缓冲（网络消息、UI 消息）；
2. TStack<T>：LIFO 栈，Push/Pop，常用于撤销栈、表达式求值；
3. TSparseArray<T>：稀疏数组（元素与索引解耦、删除 O(1) 不搬动），是 TMap/TSet 的底层结构；相关还有 TBitArray（位数组）、TIndirectArray（非拷贝对象数组）；
4. 应用：UI 撤销/重做、消息队列、对象池、事件系统缓冲；
5. 易错：TQueue 不是线程安全的，多线程队列需加锁或使用 UE 提供的线程安全队列/TSpsc（见 11.10）；TSparseArray 删除后索引空洞，遍历需处理。

考点： 缓存友好、内存布局

参考答案：

1. 游戏性能瓶颈常在缓存未命中：顺序访问连续内存远快于随机/链表跳转；
2. AoS（Array of Structs）：struct S{float x,y;}; S arr[N];，每个元素完整连续，适合"整对象一起处理"；
3. SoA（Struct of Arrays）：float X[N]; float Y[N];，同字段连续，适合"只处理某字段"或 SIMD 向量化，避免无关数据占缓存；
4. UE 例子：粒子系统、Mass ECS 数据布局采用 SoA；物理与动画批量处理注意缓存；
5. 实践：避免在循环里随机访问大数组、减少指针间接层（一串 -> 解引用）、for (const auto&) 遍历、数据按访问模式重排。

考点： 内存分配、new/delete、FMemory

参考答案：

1. new = 分配内存 + 调用构造函数；delete = 调用析构函数 + 释放内存；malloc/free 只分配/释放内存，不构造/析构；
2. new[]/delete[] 用于数组，必须配对；new 失败默认抛 std::bad_alloc（可 nothrow），malloc 失败返回 NULL；
3. UE 全局重载 operator new/delete，把所有 C++ 分配重定向到 FMemory::Malloc/Free，从而走引擎内存池（统一统计、对齐、Leak 检测、线程本地缓冲）；
4. 注意：UObject 禁止直接 new，必须 NewObject；重载了 operator new 的类（如 FRunnableThread、部分引擎类）保持一致用引擎分配器；
5. 排查内存异常：用 -memreport、stat memory、LLM 定位分配来源。

考点： 内存布局、存储期

参考答案：

1. 五大内存区：
   • 栈：局部变量、函数参数，自动分配释放；
   • 堆：new/malloc 动态分配，手动/智能指针/GC 管理；
   • 全局/静态区：全局变量、static 变量（程序生命周期）；
   • 常量区：字符串字面量等只读数据；
   • 代码区：函数机器码（只读）。
2. 四种存储期：自动（栈）、动态（堆）、静态（全局/static）、线程存储期（thread_local）；
3. 陷阱：跨编译单元的全局对象初始化顺序不定（static initialization order fiasco）；UE 中慎用静态全局对象，优先 Subsystem；
4. 常见问题：深递归/大局部数组 → 栈溢出；小对象频繁分配 → 堆碎片（见 6.4）。

考点： 内存泄漏、检测工具

参考答案：

1. 泄漏：分配后既未释放又丢失指针（或引用环无法打破），内存持续增长最终 OOM/崩溃；
2. 检测手段：
   • 工具：Valgrind / AddressSanitizer / Dr. Memory；
   • UE：LLM（LowLevelMemTracker，stat LLM）、-memreport、内存快照对比、obj list（UObject 列表）；
3. UE 专属泄漏场景：
   • UObject 被强引用链持有不释放（没 RemoveFromRoot、被 UPROPERTY 链拽住）；
   • 共享指针循环引用（见 2.4）；
   • 委托没解绑导致对象无法销毁；
   • 资源没释放（软引用转硬引用）。
4. 预防：RAII、所有权清晰、容器生命周期管理、模块 Shutdown 释放、AddToRoot 用后必删；
5. 关键指标：稳定运行后内存仍持续增长 = 疑似泄漏，优先排查 UObject/资源。

考点： placement new、对象池、就地构造

参考答案：

1. placement new：new(ptr) T(args) 在指定内存地址构造对象，本身不分配内存；
2. 释放：不能 delete，必须显式调用析构 ptr->~T(); 再释放内存块；
3. 用途：
   • 内存池：预分配大块内存，对象反复复用，避免系统分配开销与碎片；
   • 容器就地构造：emplace 底层就用 placement new；
   • 与 alignas/对齐内存配合构造对齐要求高的对象；
4. UE：引擎内部大量使用（FMemory::Malloc 后 placement new）、TInlineAllocator 就地构造、池化分配器（对象池）；
5. 易错：placement new 后必须析构再释放内存（否则资源泄漏）；目标内存必须满足对象对齐要求；不要对已构造对象重复 placement new。

考点： 对齐、padding、SIMD

参考答案：

1. 对齐：对象起始地址必须是最宽基本类型大小的整数倍（如 double 8 字节）；编译器在结构体成员间插入 padding 保持对齐；
2. 影响：
   • 结构体 sizeof 可能大于成员之和（内存浪费）；
   • 未对齐访问在 x86 上性能下降，在 ARM 上可能直接崩溃/异常；
3. 控制：alignas(N) 指定对齐、alignof(T) 查询对齐；UE 有 FORCE_ALIGN、ALIGNAS、__declspec(align) 宏；
4. 应用：SIMD 向量（如 FVector4、UE 的 alignas(16) 数学类型）、缓存行对齐避免伪共享（见 11.10）；
5. 注意：new/malloc 默认对齐通常 ≥8/16，自定义 placement 内存要保证满足对齐；序列化按对齐布局与平台字节序处理。

考点： 堆栈、内存分配

参考答案：

1. 栈：速度快（栈指针移动）、自动释放、容量小（默认几 MB）、LIFO、局部变量/函数调用帧；
2. 堆：速度慢（系统调用+锁）、手动/智能指针/GC 管理、容量大、任意释放顺序、可能碎片化；
3. 游戏实践：小的短生命周期对象放栈（循环内结构体）；大对象、动态长度、需长期存活放堆；避免深递归导致栈溢出；
4. UE 中：Actor 等 UObject 在堆；函数临时对象在栈；TArray 元素在堆（TInlineAllocator 内联部分除外）；
5. 结论：能栈分配就栈分配，需要动态大小/生命周期才堆；帧内频繁分配优先考虑对象池。

考点： 悬垂、UB、指针返回

参考答案：

1. 悬垂指针/悬垂引用：指向已销毁对象的指针/引用，访问即未定义行为（UB），常见于返回局部对象引用、回调捕获 this、容器重分配后持旧指针；
2. 不要用 memcpy 拷贝对象：对含虚函数（破坏 vptr）、管理资源（句柄/指针双重释放）或非平凡类型的对象 memcpy 是 UB，应使用拷贝构造/赋值；
3. 返回容器内部指针/引用：GetData()/成员引用返回后容器再插入/删除会使指针失效；需要长期持有应返回拷贝或约定"调用期间容器不变"；
4. 排查：ASan/UBSan、UE USE_CHECKED_STL、开启指针追踪与断言；
5. 面试追问点：const T& 成员返回、TArray::GetData 在 Reserve 扩容后失效、FString 的 * 取 C 指针在字符串被修改/析构后悬垂。

考点： GC、标记-清除、可达性

参考答案：

1. UE 的 GC 是标记-清除（Mark-Sweep），不是引用计数：UObject 本身没有引用计数字段，靠 GC 周期性扫描判定存活；
2. 工作流程：
   • 从 GC Root 集合出发（根集包括 RootSet 对象、CDO、正在执行的 UObject、全局/静态引用等）；
   • 沿 UPROPERTY 声明的强引用遍历标记所有可达对象；
   • 标记结束后，未标记的对象视为不可达，进入清除流程（PendingKill → 销毁）；
3. 关键：只有 UPROPERTY 声明的成员引用会被 GC 追踪；普通 C++ 成员/容器（无反射）即使指向对象也不会阻止回收；
4. 触发：周期性（默认约 60 秒一次，gc. 前缀 CVar 可调）、内存压力、场景切换、手动 ForceGarbageCollection；
5. 现代 UE 用增量式 GC 把标记工作分摊到多帧，减少单帧卡顿；运行时与编辑器行为略有差异。

考点： Root 集合、AddToRoot、可达性

参考答案：

1. GC Root 集合是可达性分析的起点，主要包括：
   • 标记了 RootSet 内部标志的对象（AddToRoot()）；
   • 类的 CDO（类默认对象，保证类型始终存活）；
   • 当前调用栈/执行上下文中被引用的对象；
   • 全局与静态 UPROPERTY 引用链上的对象；
2. 只要从某个 Root 出发能沿 UPROPERTY 强引用链到达的对象，GC 就不会回收；
3. 手动 Obj->AddToRoot() 让对象进入根集不被回收，用后必须 RemoveFromRoot()，否则永久泄漏；
4. TWeakObjectPtr/TSoftObjectPtr（软引用）不参与标记，不阻止回收；
5. 易错：C++ 裸成员指针持有 UObject 但没有 UPROPERTY → GC 照常回收，这是最常见的"UObject 神秘消失"原因（见 2.5）。

考点： 防回收、GC 时机、IsValid

参考答案：

1. 防止回收的三种手段：
   • UPROPERTY 强引用（推荐，如 TObjectPtr<T>）；
   • AddToRoot()（慎用，容易泄漏）；
   • 被活跃对象（Actor/Component/Subsystem）的引用链间接持有；
2. 回收时机：
   • GC 运行时发现不可达；
   • 对象被 MarkPendingKill/Destroy/关卡卸载后，在后续 GC 中真正清除；
   • 编辑器下对象被删除（软删除）；
3. 有效性判断：IsValid(Obj)（含 PendingKill 与析构检查）、TWeakObjectPtr::IsValid()、Obj->GetClass() 前置判空；
4. 注意：持有者本身被回收时，其 UPROPERTY 引用的对象若无其他引用，会连带回收；
5. 常见误用：在 Tick/回调里用缓存裸指针访问对象，未在对象销毁时清引用 → 崩溃（见 4.2）。

考点： GC 频率、强制 GC

参考答案：

1. 默认周期：引擎 Tick 中定期触发（约 60 秒一次），可用控制台变量（gc.*）调整频率与开关；
2. 其他触发：关卡切换（Map 卸载）、内存不足（平台内存告警/OOM 前）、GEngine->ForceGarbageCollection(true) 手动全量收集；
3. 增量式 GC：分帧执行标记减少单帧卡顿；UGarbageCollection 相关统计可看 stat gc；
4. 调试命令：控制台 obj gc（立即 GC）、obj list（对象列表）、gc.DumpPoolStats 等；
5. 易错：手动强制 GC 可能引起性能尖峰，战斗/直播等关键帧慎用；异步加载期间避免强制 GC 中断资源流送。

考点： PendingKill、销毁、UE5

参考答案：

1. PendingKill：对象被标记"待销毁"（如 Destroy()、关卡卸载、编辑器删除），此时对象还占用内存、IsPendingKill() 返回真，在随后的 GC 中真正清除；
2. 销毁流程：MarkPendingKill() → 脱离引用链/解除委托 → GC 标记阶段跳过 → 销毁对象并回收内存（对象池/引擎内存池）；
3. UE5 变化：弱引用（TWeakObjectPtr）在对象销毁时自动置空；IsValid() 语义更严格；UE5 推荐用 TObjectPtr 并在访问前判空，减少对裸指针的依赖；
4. UE5 中对象销毁后，未被标记的引用若被访问通常直接断言/崩溃（安全检查更严格），所以仍要遵守"先判活"；
5. 实践：在对象销毁时主动断开引用（委托解绑、容器清理），比依赖 PendingKill 更稳妥。

考点： 反射宏、UHT

参考答案：

1. UCLASS：标记 UObject 派生类，声明其成为反射类型；可带说明符（BlueprintType、EditInlineNew、NotBlueprintable 等）与元数据；
2. UPROPERTY：标记反射属性，参与 GC 追踪、序列化、网络复制、编辑器与蓝图访问；说明符如 VisibleAnywhere/EditAnywhere/BlueprintReadWrite/Replicated/Category 等；
3. UFUNCTION：标记可被蓝图调用/覆盖/网络同步的函数；说明符如 BlueprintCallable/BlueprintImplementableEvent/BlueprintNativeEvent/Server/Client/NetMulticast/Reliable；
4. 原理：UHT 在编译前解析这些宏，生成 *.generated.h 的注册代码（类型信息、属性、函数包装），运行时 UClass 持有完整元数据；
5. 易错：类内漏写 GENERATED_BODY() 编译失败；宏里的说明符是字符串形式，不能放运行时表达式。

考点： 反射原理、元数据结构、ProcessEvent

参考答案：

1. 反射（Reflection）让程序在运行时查询与操作自身结构：类型查询、动态属性访问、动态函数调用、序列化、GC 遍历、蓝图互操作；
2. 元数据结构：UField 是所有反射字段基类；UStruct 派生 UClass（UObject 类）、UFunction（函数）、UScriptStruct（值类型结构）；属性用 FProperty（UE5 值类型，替代旧 UProperty），按类型分为 FObjectProperty、FArrayProperty、FStructProperty 等；
3. UHT 把宏展开成注册代码写入 .generated.h：提供 StaticClass()、Super::StaticClass()、属性注册（含内存偏移）、函数包装（thunk 转调 C++ 实现）、序列化与复制钩子；
4. 遍历与动态调用：

UClass* C = Obj->GetClass();
for (TFieldIterator<FProperty> It(C); It; ++It) { /* 遍历属性 */ }
Obj->ProcessEvent(SomeUFunction, ParamsBuffer);   // 动态调用函数

5. 代价：反射元数据占内存、初始化有开销；模板/虚函数不能直接反射，必须走宏声明。

考点： UHT、generated.h、代码生成

参考答案：

1. UHT 是 C++ 编译前运行的代码生成工具，扫描头文件中 UCLASS/UPROPERTY/UFUNCTION/USTRUCT/UENUM/UINTERFACE 等宏，解析说明符与元数据；
2. 为每个含反射声明的头文件生成 *.generated.h（UHT 生成）与对应的 .gen.cpp（注册函数实现）；
3. generated.h 内容：GENERATED_BODY() 展开的构造/注册声明、StaticClass()/GetClass() 实现、FProperty 注册与偏移、UFunction 包装（thunk）、序列化/复制钩子；
4. 在编译期完成反射元数据构建，运行时零解析成本；UHT 由 UBT（UnrealBuildTool）自动调用，输出文件参与编译；
5. 注意：修改反射头后 UHT 需重新生成；不要手改 generated 文件；一个反射类的声明必须完整位于同一头文件；UHT 对宏、括号、注释有严格要求（如括号配平）。

考点： 反射类型层次、USTRUCT

参考答案：

1. 三者都继承 UField，本质上都是 UStruct（持有成员属性列表），但用途不同：
   • UClass：UObject 类（UCLASS），有实例对象、生命周期与 GC、网络复制、蓝图类，支持继承；
   • UScriptStruct：值类型结构（USTRUCT，如 FVector、自定义 FStruct），栈上分配、按值拷贝，无 GC、无网络复制（可自定义序列化/复制）；
   • UFunction：函数（UFUNCTION）；
2. 选择：需要对象生命周期/GC/网络复制/蓝图类 → UCLASS；只是数据结构 → USTRUCT（轻量、值语义）；
3. UClass 特有：CDO（ClassDefaultObject）、SuperClass 继承链、GetDefaultObject()；UScriptStruct 有 StructType 查询（GetScriptStruct()）；
4. USTRUCT 内引用 UObject 成员需 UPROPERTY 并注意所有权（值类型生命周期由持有者负责，GC 不追踪 USTRUCT 自身）；
5. 易错：USTRUCT 不能用 NewObject（非 UObject）；USTRUCT 内嵌 USTRUCT 成员时内存拷贝注意深/浅。

考点： 宏展开、generated.h

参考答案：

1. GENERATED_BODY()：现代推荐写法，不在类体内预生成构造函数声明；构造函数、析构、初始化需自己实现，灵活度高；
2. GENERATED_UCLASS_BODY()（旧，UE3 遗产）：预声明带 const FObjectInitializer& 参数的构造函数，限制构造方式；迁移到 GENERATED_BODY 更现代；
3. 位置要求：必须放在类定义的最末尾（所有成员声明之后、类右括号之前）；
4. 原理：该宏展开为 UHT 生成的接口声明（内部注册函数、StaticClass 等），实际实现位于 .generated.h/.gen.cpp；
5. 注意：不能在类内重复书写多个 GENERATED 宏；宏需要 .generated.h 头文件放在本头文件最后一行 include。

考点： 属性说明符、编辑器/蓝图暴露

参考答案：

1. 可见性与编辑性：
   • VisibleAnywhere：详情面板只读显示；
   • EditAnywhere：可在详情面板与默认值编辑；
   • VisibleDefaultsOnly/EditDefaultsOnly：仅限类默认对象（CDO）查看/编辑；
   • VisibleInstanceOnly/EditInstanceOnly：仅限关卡实例查看/编辑；
2. 蓝图：BlueprintReadOnly/BlueprintReadWrite（蓝图读写）、BlueprintAssignable（委托可绑定）、BlueprintCallable；
3. 网络/序列化：Replicated（属性复制）、ReplicatedUsing=Func（复制后回调）、SaveGame（存档）、Transient（不保存不复制）、Config（写入 ini）；
4. 组织与约束：Category="X"（面板分类）、meta=(UIMin, UIMax, ClampMin, ClampMax, Tooltip) 等元数据；
5. 默认值写法：UPROPERTY(EditAnywhere, Category="Movement") float Speed = 100.f;；
6. 易错：属性类型必须是 UHT 支持的反射类型（内建/容器/UObject/结构）；不能用 UPROPERTY 修饰 lambda、裸指针到无反射类型、模板字段。

考点： CDO、默认值、原型模式

参考答案：

1. CDO 是每个 UClass 的"类默认对象"，保存该类属性的默认值；通过 GetClass()->GetDefaultObject() 获取；
2. 作用：
   • 存储类默认属性，蓝图在其上做覆盖；
   • 新建对象时以 CDO 为模板拷贝默认值（原型模式）；
   • 蓝图默认值面板展示的就是 CDO 的扩展；
3. 创建时机：类首次被加载/首次实例化时构造一次，进程内通常只有一个 CDO；
4. 注意事项：构造函数内的初始化会写入 CDO；修改 CDO 会影响所有后续新对象，编辑器里改动默认值即改 CDO；
5. 实践：构造时用 CreateDefaultSubobject 创建组件并设默认值，运行时再复制；不要运行时长期修改 CDO 作为实例数据。

考点： 构造流程、CreateDefaultSubobject

参考答案：

1. 创建流程：NewObject 分配内存 → 调用构造函数（传入 FObjectInitializer）→ 注册进 GC/所属链 → 返回对象；Actor 额外还有 SpawnActor → 组件注册 → ConstructionScript；
2. FObjectInitializer 提供的关键能力：
   • CreateDefaultSubobject<T>(Name)：在构造函数中创建默认子对象（组件），参与默认对象与序列化；
   • SetDefaultSubobjectClass：替换默认组件的具体类；
   • ObjectInitializer 沿继承链传递，保证基类/派生类构造使用同一初始化器；
3. 顺序：先基类构造（同一 ObjectInitializer）→ 本类构造（成员初始化 + CreateDefaultSubobject）；
4. 规则：构造函数里只能创建默认子对象与初始化值，不能 SpawnActor、不能 NewObject 非默认对象、不能调用虚函数（见 1.8）；
5. 易错：默认子对象用 UPROPERTY 持有（否则 GC 不追踪）；需要初始化但不想放构造函数 → PostInitializeComponents/OnConstruction/BeginPlay。

考点： 蓝图调用、反射分发

参考答案：

1. C++ 函数通过 UFUNCTION(BlueprintCallable) 暴露给蓝图：蓝图节点实际调用该函数的 UFunction，经反射分发回 C++ 实现；
2. 调用链：蓝图执行 → 找 UFunction → 参数写入反射布局的缓冲区（FProperty 序列化）→ ProcessEvent 反射分发 → 引擎生成的 thunk 函数解包参数并调用 C++ 实现；
3. 两种实现方式：
   • BlueprintImplementableEvent：C++ 只声明不实现，蓝图必须实现；
   • BlueprintNativeEvent：C++ 提供默认实现（生成 _Implementation 版本），蓝图可覆盖；
4. 性能：反射调用比直接函数调用慢（动态分发 + 参数打包），游戏热路径应避免频繁蓝图调用 C++；
5. 调试：C++ 断点进不了蓝图实现可查对应 _Implementation；注意参数名、Category 影响蓝图节点名与分组。

考点： 三种字符串、本地化、性能

参考答案：

1. FString：可变字符串（类似 std::wstring），支持拼接/修改，重量级；底层是 TCHAR 动态数组；用于需要修改的文本；
2. FName：不可变字符串，全局字符串表（哈希查找、不区分大小写比较），用于标识符（对象名、Tag、动画曲线名、Socket 名）；创建的新名称会加入全局表常驻，重复创建同名不会重复存数据，但注意不会释放（调试期大量临时 FName 会涨内存）；
3. FText：本地化文本，基于 FString + 文化信息，支持多语言（LOCTEXT/NSLOCTEXT），用于显示给玩家的文本；
4. 使用规则：
   • 标识符/查找键 → FName；
   • 玩家可见文本 → FText（支持本地化）；
   • 需频繁修改/拼接/运行时生成 → FString；
5. 性能：FName 查找比较最快（哈希+索引）；FString 拼接慢（反复重分配），循环内避免构造临时 FString（用 FStringBuilder）；转换：FName(*Str)、FText::FromString(Str)、Name.ToString()。

考点： 编码规范、前缀

参考答案：

1. 类前缀：T（模板类，如 TArray）、U（UObject 派生）、A（Actor 派生）、F（结构体/普通类，如 FVector）、E（枚举）、I（接口）、S（Slate 控件）、G（全局）、B（bool 前缀）；
2. 变量：驼峰命名；bool 用 b 前缀（bIsDead）；成员习惯以 _ 或大小写区分（UE 官方较少用 m_）；
3. 函数：动词开头；取属性 GetXxx、设属性 SetXxx、判断 IsXxx/HasXxx/CanXxx；
4. 其他：字符串常量用 TEXT() 宏包裹；头文件 pragma once；#include "Xxx.generated.h" 必须放在头文件最后；
5. 意义：前缀帮助快速区分类型体系，编辑器/工具/反射部分依赖此类约定（如 UPROPERTY Category 命名）。

考点： 委托类型、绑定、动态委托

参考答案：

1. 类型：
   • DECLARE_DELEGATE（单播）：最多绑定一个回调，可重绑（Bind），用于一对一的回调/异步结果；
   • DECLARE_MULTICAST_DELEGATE（多播）：可绑定多个回调，按绑定顺序广播（Broadcast），用于事件/观察者；
   • DECLARE_DYNAMIC_*（动态）：可被蓝图绑定/序列化/存档，底层基于 UFunction 反射（存函数名），有返回值版本为签名一致性限制；
2. 绑定方式：BindUObject（UObject 弱引用，自动解绑）、BindRaw（裸指针，需手动防悬垂）、BindSP（TSharedPtr）、BindLambda、BindWeakLambda（弱引用 lambda）、AddUObject/AddDynamic（动态多播）；动态委托的 AddDynamic/BindDynamic 由宏自动生成 UFunction 查找与弱引用；
3. 底层：非动态委托存函数指针（C++ 直接调用，快）；动态委托存 FName（UFunction 名），通过反射 ProcessEvent 调用（慢但可序列化、蓝图友好）；
4. 选择：蓝图可见/需保存 → 动态；纯 C++ 热路径 → 非动态；
5. 易错：BindRaw/裸 lambda 捕获 this 不防悬垂（见 4.2）；BindUObject/AddDynamic 绑定时若对象销毁会自动解绑；广播时若回调里解绑/销毁对象要复制列表后再遍历（见 10.2）。

考点： 观察者模式、事件解绑、广播安全

参考答案：

1. 观察者模式：事件源（Subject）持有订阅者列表（Delegate 绑定列表），状态变化时 Broadcast 通知所有订阅者，实现发布/订阅解耦；
2. UE 实现：多播委托（FOnActorHit 等）、组件/ Actor 上的事件、GEngine 事件、UI 的委托；
3. 生命周期陷阱：订阅者销毁时必须解绑（动态委托/BindUObject 自动处理，BindRaw/手动绑定需在析构里 Unbind/RemoveAll）；
4. 广播期间修改列表：回调中若增删订阅者会破坏迭代 → 引擎广播前会复制列表，但回调里销毁自己仍需注意；
5. 线程陷阱：跨线程 Broadcast 需要锁或把事件派发回目标线程（见 11.10）；回调里避免长耗时操作；顺序敏感的业务注意绑定顺序。

考点： GameThread、RenderThread、线程职责

参考答案：

1. 主要线程：
   • GameThread：游戏逻辑、蓝图、Actor/Component 生命周期、UI（UMG）——绝大多数业务代码所在线程；
   • RenderThread：渲染命令构建与渲染资源访问；
   • RHIThread：图形 API（DX/Vulkan/Metal）提交；
   • AudioThread：音频逻辑；
   • 其他：网络线程、物理线程（Chaos/PhysX）、Worker 线程池等；
2. 线程间通信：GameThread 与 RenderThread 通过命令队列（ENQUEUE_RENDER_COMMAND）交换，通常传数据拷贝而非共享对象，避免竞争；
3. 线程限制：UObject/UActor 的绝大多数操作只能在 GameThread；渲染资源只能在 RenderThread；跨线程直接操作会崩溃/数据竞争；
4. 检测：check(IsInGameThread())、IsInRenderThread()、FTaskGraphInterface 线程归属；引擎对跨线程 UObject 访问在 Debug 下会断言；
5. 异步 API 全景：FRunnable（原始线程）、Async()/AsyncTask()（线程池）、FThreadPool、TaskGraph（依赖调度）、ParallelFor（并行循环）、TFuture/TPromise、UE5 的 UE::Tasks。

考点： std::thread、标准库线程

参考答案：

1. C++11 标准线程库：std::thread、std::mutex、std::condition_variable、std::atomic、std::future/std::promise、thread_local；
2. std::thread 特性：栈上句柄、创建后必须 join()/detach()、创建销毁开销较大；
3. UE 中一般不直接用 std::thread，改用引擎封装：FRunnable + FRunnableThread::Create（自定义线程）、Async/AsyncTask（线程池任务）、FTaskGraph（依赖调度）；
4. 原因：UE 线程需要命名/统计/调试栈支持、与引擎内存与平台抽象一致（如 FPlatformMisc::CreateEvent）、可集成 TaskGraph 与渲染线程依赖；
5. 结论：纯算法工具库可用 std::thread；UE 业务代码用 FRunnable/Async/TaskGraph。

考点： 异步模型、任务调度

参考答案：

1. Async(EAsyncExecution::ThreadPool, Lambda)：把任务丢进引擎线程池执行，返回 TFuture（Wait/IsReady 查询）；AsyncTask(ENamedThreads::AnyThread, Fn) 类似；
2. FRunnable：实现 Init()/Run()/Exit()，用 FRunnableThread::Create 启动为独立线程，适合长期运行的自定义线程（如 IO 线程）；
3. TaskGraph：FGraphEventRef/FGraphEvent，任务可声明依赖（A 完成后执行 B）、可指定线程归属（AnyThread/GameThread/RenderThread）、支持跟踪与统计；
4. 回到主线程：AsyncTask(ENamedThreads::GameThread, [=]{...}) 或 TaskGraph 指定 GameThread；UE5 推荐新任务系统 UE::Tasks::Launch/UE::Tasks::TTask；
5. 易错：lambda 捕获 this 需判活（见 4.2）；线程池任务共享可变数据要加锁；不要在 Worker 线程里访问 UObject（见 11.8）。

考点： 同步原语、锁粒度

参考答案：

1. 互斥锁（std::mutex/FCriticalSection）：互斥访问，读写都串行；简单可靠，竞争高时性能差；
2. 读写锁（std::shared_mutex/FRWLock）：允许多读单写，读多写少场景性能更好；写者可能饿死读者；
3. 原子变量（std::atomic/FPlatformAtomics）：无锁，适合计数器/标志/单变量；只能解决单变量原子，复合操作仍需锁（见 11.6）；
4. 选择原则：写多/竞争小 → 互斥锁；读多写少 → 读写锁；单值计数/标志 → 原子；临界区极短且自旋可接受 → 自旋锁/原子；
5. 易错：锁粒度太大是性能瓶颈；多把锁的加锁顺序不一致会死锁（见 11.7）；用 RAII（FScopeLock/std::lock_guard）保证异常时解锁。

考点： 同步、唤醒、一次性结果

参考答案：

1. 条件变量（std::condition_variable）：线程等待某条件成立再被唤醒；必须配合互斥锁使用；防虚假唤醒用 while (谓词) wait(...) 循环检查；
2. UE 的 FEvent：平台事件对象（FPlatformProcess::GetSynchEventFromPool 创建），Trigger()/Wait(ms)；类似 Win32 Event，用于通知型同步；
3. std::future/promise：一次性结果传递，promise.set_value(v) → 另一线程 future.get()；UE 对应 TFuture/TPromise（配合 Async/AsyncTask，Then 链式回调）；
4. 选择：需要结果回传 → Future；只需唤醒 → FEvent/条件变量；复杂依赖 → TaskGraph 任务；
5. 易错：等待必须考虑超时（Wait(Time) 避免死等）；future.get() 只能调用一次；条件变量等待条件变化时需再检查谓词避免丢失唤醒。

考点： 原子、内存序、CAS

参考答案：

1. std::atomic/UE FPlatformAtomics：对变量的单次读写是原子的（不会被撕裂），适合计数器、标志位；
2. 内存序（memory order）：relaxed/acquire/release/seq_cst 控制读写的可见性与重排；默认 seq_cst 最安全但较慢；多核下编译器与 CPU 都可能重排，需要内存序约束；
3. 关键认知：原子只保证"单个变量操作不可分割"，不保证复合操作原子：如"先读后改、判断后再操作"必须用 CAS（compare_exchange）循环或加锁；

int expected = c.load();
while (!c.compare_exchange_weak(expected, expected + 1)) { /* expected 已被更新为最新值，重试 */ }

4. 陷阱：if (atomicCount == 0) atomicCount++ 仍可能竞争（检查与修改之间可插入其他线程）；
5. UE：FPlatformAtomics::InterlockedIncrement、TAtomic<T>（UE5）、TSpinLock/TSynchronized<T> 封装了原子 + 锁的常用组合。

考点： 无锁、CAS、ABA、volatile

参考答案：

1. 无锁编程：用 CAS/原子指令实现无阻塞并发（Lock-free），避免锁引起的阻塞、死锁、优先级反转；
2. 实现要素：CAS 重试循环、ABA 问题（用版本号/标记位区分相同地址的不同状态）、内存序保证可见性；
3. 难度：正确性极难验证、可移植性差、Debug 困难；游戏里仅用于高性能热点（如 UE 的 TSpsc 单生产者单消费者队列、引用计数）；
4. volatile 陷阱：volatile 只保证"编译器不优化掉对内存的读写"，不提供原子性、不加锁、不保证多线程安全；CPU 仍可乱序，多线程同步必须用原子/锁；
5. 结论：默认用锁；只有确定是热点且结构简单才考虑无锁，且必须有充分的正确性论证与测试。

考点： 并发概念、死锁条件

参考答案：

1. 死锁：多个线程互相等待对方持有的锁而永不前进；四个必要条件（互斥、持有并等待、不可剥夺、循环等待），打破任一即可避免；
2. 活锁：线程反复尝试但始终无法取得进展（如互相谦让后原地打转）；饿死：某线程长期拿不到资源；
3. 数据竞争（Data Race）：两个线程无同步地访问同一内存且至少一个写 → 未定义行为，用原子/锁消除；
4. 竞态条件（Race Condition）：执行结果依赖线程调度顺序的逻辑错误——即使没有 data race 也可能存在 race condition（如"先检查后使用"的非原子序列）；
5. 预防：锁顺序全局一致、锁持有时间尽量短、不在持锁时调用外部回调/UI（可能反向加锁）、std::lock/FScopedLock 同时锁多把、必要时锁超时/诊断（UE 的死锁检测开关）。

考点： UObject 线程安全、回主线程

参考答案：

1. UObject 默认不是线程安全的：修改属性、调用 UFUNCTION/蓝图、Spawn/Destroy 必须回 GameThread；渲染线程只读渲染资源；
2. 跨线程访问规范：
   • 用 AsyncTask(ENamedThreads::GameThread, ...) / ENQUEUE_RENDER_COMMAND 把操作调度回目标线程执行；
   • 共享数据用只读快照（Worker 算完复制结果回主线程），或加 FCriticalSection 保护；
3. UPROPERTY 只声明"是反射属性"，不自动线程同步；跨线程改 UPROPERTY 是数据竞争；
4. 线程安全的读取例外：部分只读属性（GetName、GetClass）在特定线程可用，但不要依赖；UObject::IsValidLowLevel 等检查也不线程安全；
5. 实践模式：Worker 线程只做纯计算（不碰 UObject），算完把值类型结果通过 TFuture/事件回主线程，由主线程应用（避免频繁跨线程同步与主线程阻塞）。

考点： ParallelFor、并行正确性、TSpsc

参考答案：

1. ParallelFor(N, Lambda)：把 [0,N) 循环并行执行（底层线程池），适合各迭代相互独立的循环；注意 Lambda 内不能写共享可变状态（需原子/每线程局部累加后再合并）；
2. 陷阱：
   • 迭代体内调用 UObject 方法/UProperty → 必须回主线程（先收集结果）；
   • 捕获 this 判活（见 4.2）；
   • 共享输出数组：用 per-thread 临时数组最后合并，或按索引独立写入（索引不重叠即可）；
   • 假共享（false sharing）：不同线程写同一缓存行 → 性能不升反降，必要时按缓存行对齐数据（见 6.5）；
3. 线程安全事件/队列：多线程向主线程投递事件——TQueue 非线程安全，需加锁包装；单生产者单消费者用 TSpsc（FMpsc/FIFO 变体）无锁实现；
4. 跨线程广播 Delegate：先拷贝列表再执行回调，防止迭代中修改列表；回调内操作限制在对应线程；
5. 建议：ParallelFor 里避免 UE_LOG 高频输出、避免调用可能加锁的库；并行粒度选择 ForceSingleThread 开关便于调试对比。

考点： 前向声明、编译依赖

参考答案：

1. 前置声明（前向声明）class FMyClass;：只告诉编译器"类型存在"，可用于声明指针/引用、函数参数，但不能创建对象、不能访问成员、不能 sizeof（需要完整定义）；
2. 作用：
   • 减少头文件包含，降低编译依赖与增量编译时间；
   • 打破循环包含（A.h 用 B 的指针、B.h 用 A 的指针）；
3. 规则：头文件中能用前置声明就尽量用（指针/引用成员、函数声明）；.cpp 里再包含完整头文件；
4. UE 限制：UHT 反射要求 UCLASS/USTRUCT 在生成前必须有完整定义（反射声明所在头文件内），前向声明的反射类型只能用于指针；容器值类型成员（TArray<T>、TMap<K,V>）需要完整类型；
5. 易错：前置声明后仍用值类型成员/调用成员方法会编译报错（不完整类型）；泛型模板的使用需要完整定义。

考点： 异常策略、错误处理

参考答案：

1. 原因：
   • 异常运行时开销与栈展开（unwind）在游戏帧内代价大、行为不可预测；
   • 与 UE 对象模型冲突：异常跨模块/DLL 传播不可控，UObject 生命周期与 GC 状态下对象清理难以保证；
   • 发布版稳定性与崩溃定位（断点/调用栈）的需求；
2. UE 默认关闭异常（-fno-exceptions//EHsc-），try/catch/throw 基本不可用；
3. 替代方案：
   • 返回错误状态：bool/枚举错误码/FResult；
   • 断言：check()（条件为假崩溃，开发期用）、ensure()（记录错误不崩溃）、verify()（保留副作用）；
   • 日志：UE_LOG(LogTemp, Error/Fatal, ...)，Fatal 会终止程序；
   • TOptional<T> 表达"可能没有值"；
4. 第三方库若强制异常：隔离到独立编译单元或单独模块编译选项（需谨慎评估）；
5. 面试加分：check/ensure 在 Shipping 版会被裁剪（ensure 也裁剪/降级），不能用它们承载业务逻辑。

考点： 热重载、迭代开发

参考答案：

1. Hot Reload（旧机制）：编辑器内重编译并替换 UnrealEditor-*.dll，通过保存对象状态、重建 UClass 元数据实现对象"迁移"，不稳定且限制多（增删 UPROPERTY 常导致崩溃）；
2. Live Coding（推荐，编辑器启用后）：后台编译进程持续监听源码改动，只重编译受影响模块并热替换二进制，无需重启编辑器，打断点、改逻辑即时生效；
3. 原理：模块卸载/重载、二进制补丁、对象布局兼容性检查、CDO 重建；Live Coding 对 UPROPERTY 布局变化（增删字段）与 UHT 生成变化仍可能需要重启；
4. 局限：不能安全热更对象内存布局变化；蓝图中已缓存旧布局的对象可能出问题；
5. 实践：纯逻辑改动用 Live Coding 提速，数据结构/UHT 变更重启；发布走常规 Build。

考点： 单例、Subsystem

参考答案：

1. 原生 C++ 单例（static 实例）在 UE 中的问题：模块卸载顺序不确定导致悬垂、编辑器/游戏运行上下文无法区分、没有生命周期回调、跨模块访问不便；
2. Subsystem：UE 提供的生命周期管理单例体系：
   • UEngineSubsystem（引擎级）、UGameInstanceSubsystem（游戏进程级）、UWorldSubsystem（关卡/世界级）、ULocalPlayerSubsystem（玩家级）、UEditorSubsystem（编辑器级）、UDynamicSubsystem；
   • 通过 GetGameInstance()->GetSubsystem<T>() 获取，自动随宿主创建/销毁；
3. 好处：生命周期明确（Initialize/Deinitialize 回调）、类型安全、天然支持编辑器/游戏双上下文、利于模块解耦；
4. 选择：跨关卡全局数据 → GameInstanceSubsystem；每关数据/逻辑 → WorldSubsystem；玩家相关 → LocalPlayer/GameInstance；
5. 易错：Subsystem 内不要用裸强引用长期持有 UObject（阻止 GC 或悬垂，用 TWeakObjectPtr）；GetSubsystem 在宿主销毁后返回 nullptr 需判空。

考点： 构建系统、模块、头文件包含

参考答案：

1. UBT（UnrealBuildTool）通过每个模块的 Build.cs 管理依赖：PublicDependencyModuleNames（公开依赖，会被传递暴露）、PrivateDependencyModuleNames（私有，仅本模块可见）、PublicIncludePaths/PrivateIncludePaths；
2. 依赖可见性：Public 依赖的 Public 头会被下游模块看到；Private 依赖不会被传递；
3. IWYU（Include What You Use）：每个 .cpp/.h 只包含其直接使用到的头文件，杜绝"间接包含依赖"，减少编译与重编译范围；
4. UHT 与 UBT 协作：反射头文件在编译前由 UHT 生成 .generated.h，UBT 自动加入依赖并纳入编译；
5. 实践：尽量用 Private 依赖、头文件用前置声明（见 12.1）、不要在头文件包含实现细节、修改头文件时评估影响范围；UE 的 IWYU 错误（IWYU. 前缀日志）提示包含不足或冗余。

考点： 友元、封装、访问控制

参考答案：

1. 优点：
   • 允许外部函数直接访问类的私有/保护成员，提高特定场景下的效率（如运算符重载 operator<<、operator+）；
   • 实现某些设计模式（如观察者模式）时更方便，无需提供大量 getter/setter；
   • 在频繁调用的性能关键路径上，避免 getter/setter 的额外调用开销；
2. 缺点：
   • 破坏封装性：友元函数可以访问类的内部实现细节，导致类的封装被削弱；
   • 增加耦合：友元函数与类的实现紧密绑定，修改类内部结构会影响所有友元函数；
   • 不可继承：友元关系不能被继承，派生类不能继承基类的友元；
   • 不可传递：A 是 B 的友元，B 是 C 的友元，但 A 不是 C 的友元；
3. 使用原则：
   • 优先使用成员函数或公开接口，只在确实需要访问私有成员且没有更好方案时使用；
   • 友元声明应尽量靠近类定义，明确其访问范围；
4. 典型场景：
   • 重载输入/输出运算符（operator<<、operator>>）需要访问类的私有成员；
   • 工厂类或辅助类需要创建/管理对象的内部状态；
5. UE 实践：引擎核心代码尽量避免友元，保持封装；工具类/调试类可能使用友元访问内部状态。

考点： 友元声明、类级别访问

参考答案：

1. 友元函数：声明某个外部函数可以访问本类的私有/保护成员，只有该函数能访问；
2. 友元类：声明另一个类的所有成员函数都可以访问本类的私有/保护成员，友元类的每个成员函数都是友元；
3. 主要区别：
   • 访问范围：友元函数是函数级别，友元类是类级别（所有成员）；
   • 灵活性：友元函数更精确控制访问范围，友元类更方便但范围更大；
   • 依赖关系：友元类引入更强的耦合（整个类的所有方法）；
4. 语法：
   • 友元函数：friend void Func(MyClass& obj);
   • 友元类：friend class OtherClass;
5. 使用建议：
   • 只需单个函数访问时用友元函数，避免过度暴露；
   • 需要多个相关函数访问时才考虑友元类；
   • 友元类可能导致隐式耦合，修改一个类会影响友元类的多个函数。

考点： 封装性、UE 设计哲学

参考答案：

1. 友元确实破坏封装：它允许外部函数/类访问内部私有成员，削弱了信息隐藏原则，增加了维护难度；
2. 但并非完全负面：
   • 封装的目的是保护类的不变量和内部状态不被随意修改；
   • 友元是在受控的前提下打破封装，用于实现必要的功能（如运算符重载、辅助类）；
   • 关键是最小权限原则：只授予必要的访问权限；
3. UE 中的使用原则：
   • 引擎核心类（AActor、UObject 等）极少使用友元，保持接口清晰；
   • 工具类（如 FReferenceCollector 遍历对象引用）可能声明为友元以便高效遍历；
   • 调试/测试相关代码可能使用友元访问内部状态；
   • 蓝图/反射相关代码几乎不用友元，因为反射系统通过元数据而非 C++ 友元工作；
4. 替代方案：
   • 提供专门的 getter/setter（更安全但可能有性能开销）；
   • 使用 pImpl 模式隐藏实现细节；
   • 提供 friend 函数但放在独立的工具文件中；
5. 最佳实践：在 UE 项目中，如果需要友元，应在代码审查中明确记录原因，并评估是否有更安全的替代方案。

考点： 内存布局、数据共享

参考答案：

1. 共用体（union）：一种特殊的数据类型，所有成员共享同一块内存，同一时刻只能存储其中一个成员的值；
2. 与结构体的主要区别：
   • 内存：结构体成员各自占据独立内存，共用体成员共享内存；
   • 大小：结构体大小大于等于所有成员大小之和（考虑对齐），共用体大小等于最大成员的大小（考虑对齐）；
   • 访问：结构体可以同时访问所有成员，共用体同时只有一个成员有效；
3. 语法：

union MyUnion {
    int IntVal;
    float FloatVal;
    char CharVal;
};

4. 用途：
   • 节省内存：当多个字段不会同时使用时（如变体类型、协议消息）；
   • 类型双关（type punning）：通过不同成员访问同一内存的不同解释（如 float 转 int，但需注意平台差异）；
   • 硬件/协议：访问固定内存布局的硬件寄存器或网络协议字段；
5. UE 中的对应：TVariant 是类型安全的联合体包装器，避免直接使用 union 的未定义行为。

考点： 内存对齐、大小计算

参考答案：

1. 大小规则：共用体的大小等于最大成员的大小（考虑对齐），所有成员从同一地址开始存储；
2. 对齐规则：共用体的整体对齐要求等于其最大成员的对齐要求；
3. 示例：

union Example {
    char a;      // 1 字节
    int b;       // 4 字节
    double c;    // 8 字节
};
// sizeof(Example) = 8，alignof(Example) = 8

4. 内存布局：
   • 所有成员共享起始地址（偏移量均为 0）；
   • 写入一个成员会覆盖其他成员的内容；
   • 读取非最后写入的成员是未定义行为（C++17 前），C++17 起允许通过活跃成员的指针访问；
5. 注意事项：
   • 不要对 union 进行位拷贝（memcpy）后读取非活跃成员；
   • 嵌套 union 时注意外层类型的对齐要求；
   • 在 UE 中，TVariant 提供了类型安全的替代方案。

考点： 内存优化、类型双关、网络协议

参考答案：

1. 内存优化：
   • 游戏中大量对象需要节省内存（如粒子系统、AI 状态、网络消息），当多个字段互斥时用 union 替代 struct；
   • 示例：AI 的状态数据（巡逻时存储路径点、攻击时存储目标 Actor、待机时无数据）；
2. 网络协议解析：
   • 网络消息通常用 union 表示不同类型的消息体，根据消息类型字段选择对应的成员；
   • 可以避免动态内存分配，直接在消息缓冲区上解释数据；
3. 硬件寄存器映射：
   • 访问硬件状态寄存器时，不同位域表示不同状态，用 union 按需解释；
4. 类型双关：
   • 快速浮点数与整数转换（如 IEEE 754 位操作）；
   • 解析二进制数据（如文件头、资源格式）；
5. UE 中的实际应用：
   • 引擎内部某些底层模块使用 union 优化内存；
   • 推荐使用 TVariant（类型安全的 union 包装器）替代裸 union，避免未定义行为；
   • FNetworkPredictionData 等网络相关结构可能使用 union 优化消息格式；
   • 实践建议：优先考虑 TVariant 或 std::variant，只在性能关键且类型安全有保障时使用裸 union。