通信方式选型对照表

UE 里有不下六种通信手段，混用的项目几乎必然出"循环依赖、空指针、耦合地狱"。这张表是我们项目 wiki 上的版本，直接拿去：

方式 耦合度 方向 适合场景 不适合
直接 Cast 调用 高（认识具体类型） 双向 类型封闭、自己项目内部 跨系统、可扩展
蓝图接口 低（只认能力） 单向调用 角色攻击敌人、机关触发 一对多通知
事件分发器 / C++ 多播委托 低（不认识订阅者） 一对多 Boss 死亡、任务完成等通知 需要返回值的调用
组件间直接持有引用 中 双向 同一 Actor 内的组件协作 跨 Actor
GameMode / PlayerController 中转 中 星型 玩家分数、关卡状态 高频数据流
蓝图函数库（无状态） 无 工具 纯计算、转换 有状态的逻辑

几条决策规则

  1. 需要返回值？ → 接口或直接调用（广播没有返回值）。
  2. 接收者可能不存在/不唯一？ → 广播。
  3. 接收者类型会扩展？ → 接口。
  4. 通信频率很高（每帧）？ → C++ 直接调用或组件引用，别走蓝图。
  5. 跨关卡的全局状态？ → GameMode/PlayerController 或子系统（GameInstanceSubsystem）。

一个常见错误：用广播做"流程"

广播是通知，不是流程控制。如果把"玩家死亡"写成：UI 订阅 OnPlayerDied → UI 里调用"重开关卡"函数——就把流程控制权塞进了表现层。正确做法：死亡流程在 C++/PlayerController 里走完（停输入、播动画、延迟、重开），广播只负责"让别人知道这件事发生了"。

本章小结

  • 六种手段按"耦合度 / 方向 / 是否要返回值"选型。
  • 广播是通知不是流程；流程控制放在 C++ 或 Controller。
  • 高频通信不下蓝图，跨关卡状态用 GameMode/子系统。