UE5动态UI开发：用结构体数组实现数据驱动界面

1. 为什么动态UI需要结构体数组

先说一下我自己的经历。早几年做UE项目时，背包系统是用一堆单独的变量硬凑出来的，物品名一个变量、图标一个变量、数量一个变量，然后直接在Widget上摆好Item_1、Item_2、Item_3……这种做法的痛处我太清楚了：UI要做成动态伸缩列表时，蓝图节点连得密密麻麻，想加一行新物品得复制三五个控件，改一次布局要动几十个变量引用，项目一打包还经常因为控件路径写错直接崩。

后来转向结构体数组，才算是把这块硬骨头啃下来了。

结构体数组，核心就一句话：把一批逻辑上相关的数据打包成一种自定义类型，再用数组方式统一管理。比如物品的ID、名称、图标、数量、品质这些字段，原本要散落在各个变量里，现在合成一个FItemData结构体，背包里的所有物品就是TArray<FItemData>。UI生成的时候，只需要遍历这个数组，一个一个创建对应的控件实例就行。

这个思路之所以在动态UI场景里特别香，是因为动态UI的本质需求就是“数据和显示解耦”。你有多少条数据，UI就生成多少个Item，数据变了，UI跟着刷新，不需要手工去管控件数量和位置。用结构体数组做数据源，UE里无论是UMG的ListView还是动态AddChild，都能直接绑定，非常顺手。

这篇文章会把从创建结构体、设计数组、搭建UI到动态生成的完整链路讲清楚，蓝图和C++两种方式都会涉及。适合刚开始接触UE动态UI的开发者，也适合那种“写完静态UI但不知道怎么让它动起来”的朋友，看完可以直接在自己的项目里落地。

2. 结构体数组解决的核心问题

2.1 传统静态UI的维护困境

静态UI的问题不在“能不能用”，而在“改起来有多痛”。假设你要做一个任务列表，任务一、任务二、任务三，每个任务三个字段：标题、进度、奖励。静态做法就是画三个Item控件，每个控件里拖三个Text，然后一个一个把内容填进去。

这套方案在任务数量固定的时候没毛病，但只要业务一变，比如要根据玩家的等级动态显示不同数量的任务，或者任务列表要在运行时从服务器拉取再刷新，静态UI立刻变成灾难。你要么预先藏好几十个Item控件挨个显隐，要么在蓝图层层嵌套WidgetSwitcher，逻辑复杂到连自己都看不懂，改一个字段要揪出三四条线重新连。

2.2 数据驱动UI的核心优势

结构体数组的思路完全反过来。先在逻辑层把数据整理成结构体数组，UI层只负责“根据数组长度创建对应数量的控件”，每个控件从数组里取对应下标的数据填入。

这个模式的好处有几个：

• 数据与显示解耦。业务层只管修改数组内容，UI自动响应，不需要手动去翻Widget里某个Text的引用。
• 数量天然动态。从3条数据改成30条，不需要动UI布局，遍历创建即可。
• 复用性强。同一个结构体数组，换个Item控件样式就可以用在背包、商店、任务等多个界面。

说到底，动态UI的本质就是让UI跟着数据走，而不是数据跟着UI走。结构体数组把数据整理成了干净统一的格式，动态UI才有了可靠的源头。

2.3 典型应用场景

哪些地方最值得用结构体数组去做动态UI？我实际接触过的场景里，这几类最常见：

• 背包/仓库系统。物品数量不固定，每件物品有ID、名称、图标、堆叠数、品质等字段。
• 任务列表/成就列表。任务条目来自玩家进度，数量随玩法动态增减。
• 商店/图鉴。条目多，需要滚动列表，还要支持筛选排序。
• 角色选择/载具列表。玩家拥有可展示的对象集合，UI按集合动态生成。

这些场景共同的特点是：数据条目数量不确定、字段结构固定、需要在运行时刷新显示。结构体数组刚好命中全部需求。

3. 结构体与数组的基础认知

3.1 结构体（Struct）是什么

结构体是一种自定义数据类型，把多个不同字段打包成一个整体。可以把它想象成一个“表格的行”，行里的每一列就是结构体的一个字段。在UE里，结构体可以包含整型、浮点型、字符串、布尔值，也可以嵌套其他结构体、包含Object引用、甚至套数组。

和类（Class）不同的地方在于，结构体是纯数据容器，不包含逻辑方法。在UE里定义一个结构体，你得到的只是一个数据模板，需要配合蓝图类或函数来处理它的逻辑。这个特性正好契合动态UI的数据源需求：我们需要的是“一份干净的数据”，而不是带一堆方法的对象。

3.2 数组（Array）与结构体的组合

数组是同一类型元素的集合，元素按索引访问。结构体数组就是“多条结构体数据的集合”，相当