UMG Designer 的属性面板里，进度条的 Percent 下拉可以直接绑定一个函数或属性。这是把双刃剑：Demo 阶段它快得离谱，生产阶段它也是 UI 性能事故的高发区。原因在于这个下拉生成的东西——上一篇编译链里出现的 FDelegateRuntimeBinding——不是数据连接，是每帧求值的函数调用。
绑定到底是什么
Designer 里做的每一次绑定，编译后变成 UWidgetBlueprintGeneratedClass::Bindings 数组里的一条记录：被绑对象名、被绑属性名、求值路径（另一个属性名或一个函数名）。运行时由 SObjectWidget 侧的 Tick 驱动：UMG 的顶层 Slate 包装 SObjectWidget 每帧调用 UUserWidget::UpdateBoundProperties（经 PreConstruct 之外的绑定更新路径），逐条对 Bindings 做：
- 按对象名找到目标
UWidget（名字查表，有缓存）； - 解析绑定源：属性路径走
FProperty反射取值，函数路径走蓝图 VM 函数调用（thunk）； - 比较新值和旧值，不同才写回控件属性。
第 2 步是成本主体。一次蓝图函数调用（哪怕是纯 getter）的开销是普通 C++ 调用的几十倍：虚拟机栈帧、参数编组、（可能存在的）局部变量清零。属性路径稍便宜，但反射取值也不白给。一个 HUD 上 30 条绑定，每帧 30 次蓝图调用——60fps 下每秒 1800 次 VM 调用，GameThread 上白烧 1~2ms 很正常。
为什么它还会传染：volatile 化
更麻烦的是第二阶效应。上一篇 Slate 架构讲过 Fast Path 缓存：控件子树绘制结果没变就能整棵跳过 Paint。但绑定求值每帧往控件属性写新值时，写入会触发 Invalidate(Paint)——只要绑定还在被求值，这个控件就永远过不了缓存。这不是实现瑕疵，是语义必然：引擎不知道你的求值函数返回值什么时候变，只能每帧问一遍、每帧重画。
所以绑定的真实成本是双份的：求值本身的 VM 开销，加上被绑控件及其父链永远失效的 Paint 开销。这也是 Slate 架构篇里 volatile 调试 HUD 一片红的常见来源。
判据：什么时候用，什么时候不用
先说该用的场景：低频、展示型的值。血条百分比（战斗中有意义的变化频率 < 10Hz）、任务计数、菜单里的玩家名——这些值每秒最多变几次，绑定的每帧求值大部分是"问了，没变"。此时手动写法（事件里 SetPercent）比绑定省不了多少，还多了胶水代码。
必须手动的事件驱动路径：高频、数值稳定期长的值。CD 冷却、伤害飘字、法力值回蓝——用 FTimer / GAS 属性变更回调 / Tick 里带阈值判断，变了才调 SetText。尤其 CD 类：绑定每帧求值 60 次里 59 次是废话，手动写只在秒位跳变时更新一次，顺带把重绘也省了。
还有一个折中：直接写 Slate 属性。SNew(STextBlock).Text(this, &UMyWidget::GetTitleText) 的 TAttribute 绑定同样是每帧求值，但它发生在 Slate 层，不经过蓝图 VM，成本量级低一档；适合已经 Native 化的代码路径。
迁移时的检查清单
怀疑绑定在拖性能时，按这个顺序查：
stat slate看 UpdateTime 是否异常——这是绑定求值的主要落点；- 开 invalidation 调试 HUD 看哪些子树常绿（未命中缓存）；
- 数一下 Widget Blueprint 的 Bindings 数量（生成类上
Bindings数组长度，obj list类的 dump 也能看到）。
迁移不必一次做完：先挑 HUD 上绑定最密的三个控件改手动（通常是血条、CD、伤害数字），stat slate 前后各截一帧对比，收益会告诉你值不值得继续。