反模式一：蓝图里的"复制粘贴"

见过最多的场面：某个工程师在蓝图里写了一段"伤害计算"，觉得挺好用，下一个怪物蓝图里又连了一遍。三个月后项目里有 30 份这段逻辑，策划说"把物理抗性公式改一下"，于是那天下午大家在 30 个蓝图里逐个找。

修复方式：把这段逻辑提炼成一个蓝图函数库（Blueprint Function Library）或者 C++ 函数，所有蓝图调用同一个。改一处，全项目生效。

反模式二：循环里做蓝图重活

// C++ 里没事，每帧 1000 个敌人各调一次也轻松
for (Enemy e : Enemies) e.UpdateMovement();

同样的循环放在蓝图里，每个对象、每个节点都过一遍虚拟机，开销乘以对象数、乘以节点数。某个项目曾因此从 60 帧掉到 22 帧，最后把这段逻辑移到 C++，帧数立刻回来。

修复方式：识别"每帧 × N 个对象"的循环，把循环体整体下沉到 C++，蓝图只负责触发。

反模式三：用蓝图做硬引用的房屋

蓝图里直接引用一个大材质、一个大模型，会导致加载这个蓝图时连带加载这些资产。你的角色蓝图引用了主菜单 UI、过场动画、所有技能特效——于是每次进入游戏，这些东西全部加载，内存和启动时间一起爆炸。

修复方式： - 用 TSoftObjectPtr（C++）或软引用（蓝图里的 Soft Object Reference）延迟加载； - 分散资源到子蓝图、按需 Load； - 用资产引用检查器（Reference Viewer）看依赖链。

第 4 章会专门讲硬引用引发的编辑器卡顿问题。

反模式四：把蓝图当数据库

"把所有技能数值填在蓝图变量里"——这是另一种形式的复制粘贴。蓝图变量改起来方便，但它不能批量查询、不能 diff、不能被策划工具消费。

修复方式：数值放 DataTable 或 DataAsset，蓝图只读取。想改全面值？表格里 Ctrl+A 然后批量编辑。

反模式五：没有父类的"平铺蓝图"

100 个敌人蓝图，全部从 Actor 直接继承，公共逻辑被复制 100 份。

修复方式：建一个 C++ 基类 AEnemyBase（或蓝图基类 BP_EnemyBase），100 个具体敌人继承它。公共逻辑在基类里一份。

一个自检清单

每次 review 蓝图时过一遍：

• [ ] 这段逻辑在项目里是唯一的吗？（否则提取公共函数）
• [ ] 它会在循环或 Tick 里高频执行吗？（考虑下沉 C++）
• [ ] 它引用了大体积资源吗？（改软引用）
• [ ] 它存了本该放数据表的数值吗？（挪到 DataTable）
• [ ] 同类蓝图共享父类吗？（建立基类）

本章小结

• 五大反模式：复制粘贴、循环重活、硬引用房屋、蓝图当数据库、平铺无基类。
• 每个反模式都有明确修复方式：公共函数库、下沉 C++、软引用、数据表、基类继承。
• 养成 review 蓝图的习惯，反模式在早期修正成本极低。

本章把"为什么混合开发"讲完了。下一章进入动手环节：C++ 如何把能力暴露给蓝图——UPROPERTY、UFUNCTION 和事件机制。