一、类型全景图：6 种原生类型 + 3 种结构类型

蓝图提供 6 种原生数据类型，覆盖了独立游戏开发中 95% 的数值与文本需求。理解它们的设计意图，比"会用"更重要。

1.1 数值三剑客：Boolean / Integer / Float

Boolean 是双态判断的载体，UE 在底层将其实现为 1 字节（实际占用 4 字节，受内存对齐影响），适合状态机标志位、解锁条件、开关类逻辑。Integer 是 32 位有符号整数，不要用 Integer 表示时间戳或大数字 ID——超过 21 亿的数值会溢出，独立游戏虽然罕见，但排行榜系统、联机匹配 ID 都有可能踩坑。Float 是 32 位单精度浮点，UE 物理与动画模块统一使用 Float，与 C++ 层的 double 转换时会有精度截断警告，移动端表现尤其需要注意。

1.2 文本三剑客：String / Name / Text

这是初学者最容易混淆的一组。String 是可变长字符串，适合运行时拼接、日志输出、玩家输入处理。Name 是不可变字符串表项，大小写不敏感、查找 O(1)，适合资源标识、枚举型标签、网络包头。Text 是本地化字符串，必须通过 FText 本地化流水线处理才能正确显示多语言，绝不要用 String 装要显示给玩家看的文本——这是独立游戏出海最常被踩的本地化坑。

编辑观点：判断"该用哪种文本类型"的金标准是问自己一个问题——这段文本是否会随游戏版本或地区而变化？会变 → Text，不会变但要快速比较 → Name，纯粹内部处理 → String。

1.3 结构三剑客：Struct / Object Reference / Class Reference

Struct 是值类型的复合数据容器，适合表达"几个字段总是一起出现"的语义（比如角色属性三件套：Health、MaxHealth、RegenRate）。Object Reference 是对象的指针，引用即耦合，是架构腐化的起点。Class Reference 是类的指针，常用于软依赖（如配置中指定要生成的 Actor 类）。

1.4 Struct vs Object Reference 的决策树

很多中级工程师都问过这个问题。Xmohe 建议按这个顺序判断：第一，数据是否需要被继承扩展？需要 → Object Reference。第二，数据是否需要被多处共享且只读？是 → DataAsset（本质是 Object Reference 的一种）。第三，数据是否只作为"打包字段"在不同函数间传递？是 → Struct。第四，数据需要异步加载吗？需要 → 软引用（Soft Reference）的 Object Reference。

二、作用域七层金字塔：变量该放在哪里

变量的"作用域"决定了它的生命周期、可见范围与访问性能。Xmohe 把 UE 蓝图中的变量按作用域划分为七个层级，从最窄到最宽依次为：

2.1 第一层：函数局部变量（Function Local）

仅在当前函数调用期间存在，是性能最友好、耦合最低的层级。能用局部变量解决的，绝不升级为类变量——这是减少蓝图腐化的第一原则。

2.2 第二层：宏局部变量（Macro Local）

与函数局部变量类似，但作用域限定在宏图内。宏的优势在于节点复用，劣势是调试栈较深。

2.3 第三层：事件局部变量（Event Local）

仅在当前事件调用栈内有效。独立游戏开发中最常见的就是 BeginOverlap 等事件触发的临时计算变量。

2.4 第四层：类成员变量（Class Member / Member Variable）

类的实例属性，是蓝图变量系统的主力。关键问题：是否所有实例都共享同一份？默认情况下是每个实例独立一份；如果你想共享，需要把变量类型标记为"Static"或在 GameInstance 中声明。

2.5 第五层：组件局部变量（Component Local）

挂在 Scene Component 或 Actor Component 上的变量，适合"只属于该组件的状态"——比如血条组件的当前生命值，独立于 Actor 自身的状态管理。

2.6 第六层：GameInstance 全局变量

跨关卡、跨场景持久存在的全局状态。适合存放"整个游戏运行期间不变"的配置（如玩家存档槽位、平台标识、全局开关）。

2.7 第七层：运行时 DataAsset

外部配置文件，是数据驱动设计的核心载体。DataAsset 既可以由设计师在编辑器中填写，也可以在运行时通过 DataTable 加载，是独立游戏"内容与逻辑分离"的关键工具。

💡 作用域选择速查表：临时计算 → 函数局部；单个 Actor 状态 → 类成员；可复用配置 → DataAsset；跨场景状态 → GameInstance。判断标准只有一条：这个变量的生命周期是否超过它所在函数？超过，则需要向上升级作用域。

三、网络复制的最小知识集合

独立游戏做多人模式时，90% 的同步问题都来自对网络复制机制的不理解。本节给出独立游戏场景下够用的最小知识集合。

3.1 服务器权威原则

UE 的网络模型是服务器权威（Server Authority）。所有的游戏状态变化，默认只在服务器上发生，客户端只是"被通知"。这是 UE 与某些其他引擎（如部分 P2P 架构）最大的不同——新手往往在客户端里直接 Set 变量，然后疑惑"为什么其他玩家看不到"。

3.2 变量复制（Variable Replication）

要让一个变量从服务器同步到所有客户端，只需要在变量细节面板里勾选 "Replicated"。但有两个常见误解需要澄清：

• 误解一：Replication = 高频同步。实际上，UE 默认只在变量值改变时才同步，不是每帧同步。
• 误解二：RepNotify 等于"在客户端调用回调"。RepNotify 确实在客户端收到复制数据时触发，但它不会在服务器本地的 Set 之后触发——如果需要服务器也响应，应在 Set 之后手动调用自定义事件。

3.3 三种 RPC 的适用边界

RPC（远程过程调用）用于"让代码在另一端执行"，分为三类：

• Server RPC：客户端 → 服务器。适合客户端输入上报、玩家操作请求。必须验证，否则就是外挂天堂。
• Client RPC：服务器 → 特定客户端。适合个性化事件（如 UI 通知、剧情触发）。
• NetMulticast RPC：服务器 → 所有客户端。适合公共事件（如爆炸、群体 Buff）。带宽成本最高，慎用。

四、Array / Set / Map 容器性能横评

独立游戏项目中，"用什么容器"是高频面试题，也是工程效率的真实分水岭。Xmohe 在三款独立游戏的实际项目中做过对比测试，结果如下（测试环境：UE 5.3，4 核 CPU，单容器 10,000 元素）：

独立游戏选型建议：

• 顺序遍历场景（敌人列表、动画队列） → Array，永远的第一选择。
• 需要快速判断"是否存在"（成就解锁、任务完成） → Set，节省 Set.Remove 的 O(n) 开销。
• 需要键值对（玩家存档、配置表） → Map，但避免在 Tick 里频繁 Find。

五、初级用户：一键抄走的使用清单

以下清单可以直接贴在你的工作台旁边，每条都是 1–2 年实际项目验证过的经验：

1. 命名用前缀法：Boolean 用 b 开头（bIsAlive），Integer 用 i / Count（iHealth），Float 用 f（fSpeed）。
2. 避免一个蓝图里超过 30 个变量。超过就应该考虑拆分类或引入 DataAsset。
3. 任何要显示给玩家的文本都用 Text，永远不要用 String。
4. 资源标识符用 Name，比如成就 ID、关卡 Tag、物品枚举。
5. 不要在 Tick 里读变量，要在事件触发时缓存到局部变量后再用。
6. 需要从关卡间保留的数据，放 GameInstance。
7. 需要被设计师在编辑器里配置的，放 DataAsset。
8. 不要滥用 Container。能用单变量解决的，不要为了"将来扩展"先开 Array。
9. Set 变量时同时设置默认值的注释，未来你（或者同事）会感谢你。
10. 复选框 "Instance Editable" 要慎用，开了之后所有实例都能改，维护成本剧增。

六、中级用户：参数化决策框架

如果你是中级工程师，需要在大型项目里设计变量系统，下面的参数化决策框架可以帮你规避 80% 的设计陷阱。

6.1 变量粒度评估

问自己三个问题：

• 这个变量的"有效读路径"在性能热路径上吗？ → 考虑提取到 Component。
• 这个变量在 Tick 里被多次读取吗？ → 缓存到 Event Begin Play 的局部变量。
• 这个变量跨多个 Actor 共享同一份值吗？ → 升级为 DataAsset 或 GameInstance。

6.2 数据驱动设计的参数模板

一个标准的"角色配置 DataAsset"应至少包含以下字段（按使用频率排序）：

• fMaxHealth（Float）
• fMoveSpeed（Float）
• fAttackDamage（Float）
• sDefaultWeapon（Name，引用武器表）
• tLocalizedName（Text，角色显示名）
• arrAbilities（Array of Name，技能标签列表）

6.3 复制策略的性能量级参考

基于实际项目测试，独立游戏常见同步对象的带宽占用大致为：

• 玩家位置（Vector）高频更新：约 8 字节/帧 × N 玩家，约 0.5–2 KB/秒/玩家。
• 玩家血量（Float）低频更新：仅在数值变化时同步，平均 < 100 字节/秒/玩家。
• 聊天文本（String）：典型 < 200 字节/条，独立游戏并发 10 人以下可忽略。

这些数字不是放之四海皆准，但能帮你建立"什么时候该用变量复制、什么时候该用 RPC"的直觉。

七、避坑 Top 10：资深工程师的真实翻车记录

Xmohe 汇总了独立游戏开发者社区里最高频的 10 个变量系统翻车场景，按严重程度排序：

1. String 装 Text 用途：海外版本所有文本显示成 raw 字符串，UI 全部失效。
2. Integer 计数超过 21 亿：排行榜系统崩溃，原因是用 Integer 存累计经验值。
3. 客户端直接 Set 复制变量：服务器从未真正持有状态，多人模式完全错乱。
4. RepNotify 期望在服务器触发：写代码逻辑依赖 RepNotify，结果服务器本地的状态不一致。
5. 在 Tick 中遍历 Array 查找：敌人数量一多帧时间骤降，10 个敌人就掉到 30 FPS。
6. 循环引用导致蓝图无法加载：A 引用 B，B 引用 A，循环引用检测报错。
7. 硬引用 DataAsset 导致内存爆炸：所有关卡一次性加载全部角色配置，浪费数百 MB 内存。
8. 变量命名歧义：Time / Timer / TimeSinceLast 等相似命名，三个月后自己都看不懂。
9. 缺少默认值注释：新同事接手时，每个变量都要点开看类型和说明。
10. 在 SaveGame 中存了不该存的对象引用：保存了 Actor Reference，加载后该 Actor 已不存在，崩溃。