1. 为什么变量类型在UE5开发里这么重要
1.1 蓝图转C++：先迈过“类型思维”这道坎
做UE5开发绕不开C++，而变量类型是整个C++编程最基础也最关键的一环。很多从蓝图转过来的朋友，刚开始学C++时最大的困惑就是：为什么写一个数值还要先声明它是什么类型？在蓝图里拖个节点就能算的东西，到C++里怎么就这么多讲究？
蓝图里变量类型其实也存在，只是引擎帮你做了大量隐式转换，你拖两根线，类型不匹配时引擎会在背后自动处理，运行期报错也常常不痛不痒。C++则完全不同，类型是编译期强约束，你定义一个变量时，编译器就为它规定了固定的内存大小和解释方式，一旦后续代码把不兼容的类型赋给它，编译直接失败。
这种“严格”一开始让人觉得束缚，但用久了会发现它是保护伞。很多在蓝图运行期才暴露的诡异问题，在C++编译期就会被拦下来。类型不对、精度损失、访问越界，编译器会明确告诉你，这比在游戏运行时调试一个崩溃要省心得多。
UE5里选择C++而不是纯蓝图，通常是为了性能敏感的计算、复杂数据结构的操作、以及需要精确控制内存的场合。而这类场合恰恰是变量类型发挥价值的地方。举个例子，一个每秒执行几百次的循环，蓝图节点调用开销远高于原生C++代码，更不用说蓝图变量本身的类型处理也有运行时开销。所以理解变量类型，本质上是理解程序在计算机里如何存放数据、如何传递数据、如何变换数据，这是引擎所有功能的地基。
1.2 int32、float、bool、double、TCHAR：基础五件套怎么用
先说一说UE5里最常用的几个内置基础类型。它们看起来和C++标准类型差不多，但引擎做了很多封装和约定，必须按UE5的规矩来。
第一个是int32。你可能疑惑，为什么UE不用C++的int？因为C++标准并没有规定int在不同平台上的固定字节数，可能是2字节、4字节或8字节。UE5项目往往要同时打包到Windows、Android、iOS、主机等多个平台，如果用int，同一个数值在不同平台上可能出现不同的溢出行为，非常难受。int32强制固定为32位有符号整数，跨平台行为完全一致。类似地还有uint8、uint16、int64等。
第二个是float。游戏开发中最常用的浮点类型，占4字节，表示范围够用。UE5里角色的移动速度、生命值、冷却时间这些参数，几乎所有蓝图节点的浮点参数，在C++里对应的默认类型就是float，不是double。写代码时有个细节：float字面量要加f后缀，比如600.0f，直接写600.0默认是double，赋值给float会有精度转换提示。
第三个是bool，占1字节，用于表示真假。UE5的命名约定喜欢在布尔变量前加b前缀，比如bIsDead、bIsRunning。这不仅仅是个习惯，更是一种代码可读性的约定，一看变量名就知道这是布尔类型。很多人觉得这是小事，但实际项目里几千个变量，命名规范能极大降低理解成本。
第四个是double，64位浮点数。UE5中需要极高精度的场景才用，比如超大世界坐标、天文数量级的模拟计算。大多数情况下用float就够了，double占的内存是float的两倍，在数组和容器里差距更明显。
第五个是TCHAR。C++的char在UE5里被封装成了TCHAR，涉及字符串时几乎都会碰到。字符串底层是TCHAR数组，而文本常量要以TEXT(...)宏包裹，主要是为了适配宽字符编码。
int32 CurrentHealth = 100; float MoveSpeed = 600.0f; double LargeDistance = 1234567.8901; bool bIsAlive = true; TCHAR FirstChar = TEXT('A');这段代码几乎就是UE5 C++里最基础变量的标准写法。声明变量后，它们会被存在栈上，函数结束自动释放，生命周期清晰，这是做游戏逻辑最常用的方式。
2. UE5独有数据类型：从FVector到FText
2.1 FVector、FRotator、FTransform：场景数据三兄弟
游戏世界是一个三维空间，UE5里最常打交道的三个结构体就是FVector、FRotator和FTransform。
FVector代表三维向量，可以用来表示坐标、方向、速度等。它有X、Y、Z三个公开分量，可以直接读写。用法上，它内置了大量常用运算，比如判断两个点的距离：
FVector PlayerLocation = GetActorLocation(); FVector TargetLocation = TargetActor->GetActorLocation(); float Dist = FVector::Distance(PlayerLocation, TargetLocation);再比如判断目标是否在自己前方，点积是最经典的做法：
FVector Forward = GetActorForwardVector(); FVector ToTarget = (TargetLocation - PlayerLocation).GetSafeNormal(); float DotValue = FVector::DotProduct(Forward, ToTarget); if (DotValue > 0.5f) { // 目标在前方大约60度夹角范围内 }点积大于0表示在前方，大于0.5表示夹角小于60度。这种计算在战斗逻辑、敌人AI、相机控制里都非常常用。另一个是叉积CrossProduct，用来判断目标在左侧还是右侧，做转向和绕行特别方便。
FRotator表示旋转，三个分量为Pitch、Yaw、Roll。使用它时有个经典问题：旋转叠加不是简单的分量相加，因为旋转是有顺序的，不同顺序会得到不同的最终朝向。所以在做平滑旋转时，我基本不用FRotator直接做插值，而是用FQuat四元数或者引擎的RInterpTo方法，避免万向锁问题。
FTransform则是“三合一”结构，包含位置、旋转、缩放。一个Actor在场景中的完整变换就是FTransform。它经常用于场景中物体的放置、层级变换、以及在不同坐标系之间转换。比如GetActorTransform()拿到完整变换，SetActorTransform()设置完整变换，底层会把位置旋转缩放一次性应用到Actor上。
这三者的关系可以这样理解：FVector回答“在哪里”，FRotator回答“朝向哪里”，FTransform回答“以什么状态待在那里”。做关卡编辑器工具、敌人出生点布置、保存加载系统时，FTransform是主要的数据载体。
2.2 FString、FName、FText：三种字符串别选错
字符串是另一个高频数据类型，但UE5里有三种，很多人一开始分不清该用哪个。选错不是不能运行，而是性能和语义都别扭。
FString是动态字符串，可以任意拼接、修改、解析。引擎内部会动态分配内存，运行期灵活度最高，但代价是创建和拷贝有开销。适合做路径拼接、动态生成文本、解析输入这些场景，不适合频繁当作字典键名来用，因为哈希计算需要遍历整个字符串，性能远低于FName。
FName是不可变的哈希化字符串，不区分大小写，内部是一个全局名字表索引。查找和比较极其快，因为底层比的其实是索引。创建FName时有向全局表注册的开销，所以它不是零成本，但一旦创建，后续比较和哈希都非常高效。用于资产名称、Tag、Socket名、输入Action名这些稳定标识最合适。
FText是面向显示的本地化文本类型。玩家界面上的文字应该用FText，因为它支持多语言系统的翻译和文本格式。直接把FString塞给UI然后显示，一旦项目要做本地化就会很被动。
我之前做过一个道具系统，刚开始图省事，所有道具名都用FString，后面加多语言时不得不大面积重构。如果你也面临选择，记住一个简单判断：用于逻辑标识的用FName，需要运行时拼接和修改的用FString，最终要显示给玩家看的用FText。
2.3 UPROPERTY：让C++变量与蓝图打通的反射开关
UE5 C++和蓝图能无缝交互，核心机制是反射系统。C++本身没有反射能力，引擎通过UPROPERTY宏在编译阶段收集变量信息，注册到引擎的反射数据库。有了反射，蓝图编辑器才能在细节面板里显示变量，才能序列化保存实例数据，才能让蓝图层读写C++变量。
UPROPERTY常见参数有：
VisibleAnywhere：在细节面板显示，但不可编辑EditAnywhere：实例细节面板和Class默认值都能编辑EditDefaultsOnly：只能在Class默认设置里改BlueprintReadOnly：蓝图只读BlueprintReadWrite：蓝图可读写Category：在细节面板里归类的名称
UPROPERTY(EditAnywhere, BlueprintReadWrite, Category = "Character Stats") int32 MaxHealth = 100; UPROPERTY(VisibleAnywhere, BlueprintReadOnly, Category = "Character Stats") float CurrentHealth;新手容易漏写UPROPERTY，导致变量在蓝图里怎么都找不到。调试半天才发现只是忘了加宏。反射机制还有一个隐含特性：加了UPROPERTY的变量会被序列化，保存到存档或关卡文件里；没加的变量不会保存，每次运行时都是代码里的初始值。这个差异在做存档系统时尤其要注意。
要注意的是，C++里成员变量的默认值并不会自动覆盖已存在蓝图实例的序列化数据。也就是说你改了C++里的MaxHealth = 100为150，已经放置在关卡里的Actor实例还是旧值。踩过这个坑之后我就明白，修改C++默认值后，要么删除旧实例重新放置，要么在实例细节面板里手动重置。
3. 容器变量：TArray、TMap与TSet怎么选
3.1 TArray：最常用动态数组的增删改查
游戏逻辑里很少只存单个数据，大多数时候要存一组数据，比如背包里的道具、敌人列表、得分排行。UE5的TArray就是最常用的动态数组。
它的底层类似std::vector，是一块连续内存。随机访问非常快，按下标访问是O(1)，遍历时缓存友好。尾部增删也高效，但中间和头部插入需要搬移后续元素，开销较大。
基本用法：
TArray<int32> Scores; Scores.Add(10); Scores.Emplace(20); // Emplace直接在容器内构造，减少临时对象 Scores.Add(30); int32 FirstScore = Scores[0]; int32 Index = Scores.Find(20); // 返回索引，找不到返回INDEX_NONE Scores.RemoveAt(1); // 按索引删除 Scores.Remove(30); // 按值删除 Scores.Sort();需要注意，范围for遍历是只读的，要修改元素需要加&引用：
for (int32& Score : Scores) { Score += 10; }遍历时删除元素是另一个经典坑。如果在一个正序遍历中调用RemoveAt，后面的元素会整体往前挪，索引错乱，轻则漏处理元素，重则崩溃。我的做法是：要么从后往前遍历删除，要么先收集要删除的索引，循环结束后统一删除。
for (int32 i = Scores.Num() - 1; i >= 0; --i) { if (ShouldRemove(Scores[i])) { Scores.RemoveAt(i); } }3.2 TMap与TSet：键值对查询与去重标记
TMap是键值对容器，底层是哈希表，查找平均O(1)。声明方式：
TMap<FName, int32> ScoreMap; ScoreMap.Add(TEXT("Player1"), 100); ScoreMap.Add(TEXT("Player2"), 200); if (int32* Score = ScoreMap.Find(TEXT("Player1"))) { // 这里*Score就是100 }Find返回的是指针，找不到时返回nullptr，所以必须判空再用。还有一种写法是FindRef，直接返回值，但键不存在时会返回默认构造的值，容易和“真值”混淆，除非你知道键一定存在，否则我建议优先用Find。
TSet是去重集合，只存储值本身，不允许重复。常用于标记类逻辑，比如“已访问过的地点”“已解锁的成就”。往TSet里重复添加同一个元素不会报错，只是不会增加数量。
TSet<FName> VisitedLevels; VisitedLevels.Add(TEXT("Level1")); VisitedLevels.Add(TEXT("Level1")); VisitedLevels.Add(TEXT("Level2")); // Num() == 2TMap不保证遍历顺序，因为哈希表的存储位置由哈希值决定。如果业务上要求按插入顺序遍历，需要额外维护一个TArray保存键的顺序。不少新手在这里踩坑：往TMap里Add几次，然后遍历，发现顺序和插入顺序完全不一样，其实这是正常现象。
3.3 容器性能：拷贝、扩容与引用传递
容器性能问题看似进阶，其实在实际开发里避不开。最常见的问题是：把一个大容器直接按值传给函数，导致整份拷贝，每一帧都发生，很快就卡顿。
正确做法是传const引用：
float CalculateAverage(const TArray<float>& Scores) { // 不拷贝，只读访问 }参数加了const和&，函数内部不能修改原数组，也不会发生拷贝。默认按值传参时，函数会复制一份整个数组，对于几百上千个元素的容器，这是完全不必要的开销。
扩容策略也是性能关键。TArray随着Add次数增加，会按一定策略扩容，也就是重新分配更大的内存并把旧数据搬过去。如果预先知道数据量，可以直接Reserve预留空间，避免反复扩容带来的性能抖动：
TArray<FVector> PointList; PointList.Reserve(10000); for (int32 i = 0; i < 10000; ++i) { PointList.Add(CalculatePoint(i)); }TMap和TSet底层是哈希表，删除元素比较多时还会有节点缓存等问题。一般来说，容器不会成为性能瓶颈，但你得养成习惯：热循环里不拷贝、不频繁Add小元素、不用FString当键。做到这几点，容器性能基本不会出问题。
4. 变量类型转换、蓝图暴露与避坑指南
4.1 字符串与数值互转，常用函数一次收好
开发时经常要把字符串和数值互转，比如解析配置文件、显示得分、拼接URL。UE5提供了几个最常用的函数。
数值转字符串：
int32 Score = 250; FString ScoreStr = FString::FromInt(Score); float Ratio = 0.75f; FString RatioStr = FString::SanitizeFloat(Ratio);字符串转数值：
FString NumberStr = TEXT("1234"); int32 ParsedInt = FCString::Atoi(*NumberStr); FString FloatStr = TEXT("3.14"); float ParsedFloat = FCString::Atof(*FloatStr);这里的*NumberStr是把FString转为底层的TCHAR指针，FCString系列的C风格函数需要这个参数。解析时建议先判断字符串是否为空：
if (!NumberStr.IsEmpty()) { int32 Parsed = FCString::Atoi(*NumberStr); }FName和FString的互转也很常用：
FName ItemName = TEXT("Sword"); FString NameStr = ItemName.ToString(); FName RestoredName = FName(*NameStr);FName转FString用ToString，FString转FName直接构造。整体来说，转换本身不复杂，难点在于记住不同函数所属的模块和用途。
4.2 蓝图里暴露变量：UPROPERTY参数上手指南
在蓝图里暴露变量，主要靠UPROPERTY宏和合适的访问权限。我的建议是：能暴露的尽量暴露，但只暴露需要调的那部分。
一开始做项目时，我习惯把所有变量都设为EditAnywhere, BlueprintReadWrite，因为感觉这样最方便，美术和策划就能随便改。但这会带来问题：变量可以被随意改动，团队协作时容易出现谁也不知道哪里改了数据的情况。正确的思路是：根据职责区分。
数值型配置，比如怪物血量、移动速度、攻击力，用EditDefaultsOnly, BlueprintReadOnly，在Class默认值里统一设置，运行期蓝图只读。需要运行时更新的状态，比如当前血量、当前弹药数，用VisibleAnywhere, BlueprintReadOnly，在局内面板观察。蓝图对外接口需要主动改的，才用BlueprintReadWrite。
Category参数也值得认真写。调试面板里几类变量混在一起时，有Category分类能极大提升查找效率，尤其是项目到中期，组件和脚本多起来后，这几乎是刚需。
4.3 踩过的坑：忘写宏、精度混乱与遍历删除
写UE5 C++这么长时间，也踩过不少变量类型相关的坑，有几个特别典型。
第一个是忘写UPROPERTY。变量本身能用，逻辑也正常，但蓝图里看不到，细节面板也没有。有时候为了找这个变量，一层层检查代码，最后发现只是少写了一个宏。所以现在写成员变量时会条件反射一样检查：这个变量需要暴露给蓝图吗？需要序列化吗？如果是，就立刻写完整UPROPERTY。
第二个是float和double混用。有个版本我为了“更精确”，把某些参数改成了double，结果蓝图里一堆节点默认是float，对接时总出现类型转换和精度提示。后来越想越明白：UE5里蓝图浮点节点普遍是float，C++侧也优先用float，除非真的有超大坐标计算需求，不然不要轻易上double。
第三个是FString当TMap键。游戏逻辑里收集玩家ID到分数映射，一开始用FString做键。运行正常，直到地图上有几百个玩家实体时出现明显卡顿。把键换成FName后，查找性能提升非常明显。从那以后，做键的字符串一律用FName。
第四个是遍历TArray时删元素。这算是老生常谈，但几乎每个新手都会遇到。第一次写敌人死亡清理逻辑时，我直接在正序循环里RemoveAt，结果一次删多个敌人就跳过了一些，部分位置出现逻辑错乱。后来改成从后往前遍历，问题立刻消失。
第五个是FText和FString混用。UI显示文本直接用了FString，后面做多语言时发现底层全要改成FText，重构范围非常大。这个教训让我定了个规矩：凡是显示给玩家的文案，一开始就必须是FText，开发和本地化后期能省掉大量返工。
这些坑看起来都是小问题，但每一个都可能成为项目推进的绊脚石。类型选择看起来是编码基本功，实际上影响的是整个项目的稳定性、性能和协作效率。我在实际开发中养成的习惯是：写任何一个变量前，先想清楚它最终会被谁使用、在哪个平台运行、会不会被蓝图读取、需不需要序列化。把这些想明白，再动手写代码，后续踩坑的概率会小很多。
