Unity事件中心设计：发布订阅解耦、类型安全与调试实践

Unity 项目做到第三个功能模块的时候，几乎一定会撞上同一类问题：UI 脚本里直接攥着玩家对象的引用，战斗脚本里又反过来调用 UI 的刷新方法，改一个数值要顺藤摸瓜改五六个文件，改完还不敢确定有没有漏。我接手过的中后期项目里，十有八九会自己长出一个叫 EventCenter、MessageCenter 或者 GlobalEvent 的类，然后所有模块都往里面塞事件。这个类本身不难写，难的是写对、用对、出了问题能迅速定位。观察者模式（发布-订阅模式）恰恰是这种场景下最朴素也最有效的解耦手段，它把“谁通知谁”从编译期的硬引用变成了运行期的松散连接。

这篇内容主要讲清楚三件事：在 Unity 里怎么设计一个类型安全、可调试、不容易泄漏的事件中心；它和 C# 原生 event、UnityEvent、ScriptableObject 事件通道之间该怎么选；以及在真实项目里最容易踩的坑长什么样。适合已经写过一点 C#、做过一两个小 Demo、但一上中型项目就被模块耦合折磨过的开发者，也适合做架构的同学拿去当团队规范的底稿。下面所有代码都可直接落地，我会把每个设计选择的“为什么”一并讲透。

1. 先把问题摆清楚：Unity 项目为什么绕不开事件通信

1.1 一次典型的耦合事故复盘

先说一个我印象很深的场景。项目里有个血量条，最初的写法很直接：玩家脚本PlayerController里持有一个HealthBarUI的引用，掉血时调用healthBar.SetValue(current, max)。整个功能只有三十行代码，改动快、逻辑直白。但两周之后，需求开始膨胀：BOSS 血条也要用同一套显示逻辑、需要在受伤时飘字、需要让音效系统播放受击音、需要让成就系统统计累计伤害。于是PlayerController里多出了三四个引用，构造函数变成了参数列表，某个 UI 预制体被删掉之后直接报空引用，整局游戏卡死。

事故发生的原因并不是“用了直接引用”，而是依赖方向反了。逻辑层不应该知道界面层的存在，界面层也不应该被逻辑层反向持有。更麻烦的是，当同一个伤害数值需要被多个系统消费时，逻辑层每新增一个消费者就要改一次代码，这叫开闭原则的违反。观察者模式解决的核心问题就在这里：发布者只管把“发生了什么”喊出去，谁关心、怎么处理，是订阅者自己的事。发布者从此不需要知道订阅者的类型、数量、存活状态。

这种改动带来的直接收益是编译期的依赖图变干净了。你可以把战斗模块和 UI 模块放进两个不同的 Assembly Definition 里，战斗模块完全不引用 UI 程序集，两边只共享事件定义所在的公共程序集。这是 Unity 项目做模块化拆分时非常实用的一招，很多团队卡在“想拆 asmdef 但拆不开”的阶段，根源就在于模块之间全是硬引用。

1.2 观察者模式和发布-订阅不是一回事

这两个词经常被混着用，但在工程实现上有明确差异，搞清楚这个差异能帮你避免很多设计上的犹豫。经典的观察者模式里，Subject 直接持有一个 Observer 列表，Observer 是一个接口，双方是互相认识的；而发布-订阅模式在中间加了一层调度器（事件总线），发布者和订阅者互不认识，只认识总线。

Unity 里我们通常需要的是后者。原因很现实：Unity 的对象生命周期由引擎管理，一个 UI 面板随时可能被销毁，如果用经典观察者模式，发布者手里拿着一个已经Destroy掉的引用，调用时就会抛MissingReferenceException。而中间加一层总线之后，订阅者可以在OnDisable里主动退订，发布者完全不感知。另外，总线可以做统一的事情：记录日志、统计调用次数、捕获异常、可视化调试。这些能力如果分散在各个 Subject 里，维护成本会高得离谱。

不过总线也不是没有代价。它把“谁调用了谁”从代码里转移到了运行时，静态阅读代码时你看不出一次伤害事件到底触发了哪些逻辑。这个缺点在小团队里不明显，在十几人的团队里会变成排查噩梦。所以后面我会专门写一节讲调试面板，这是我在实际项目里认为必须补上的一环，否则总线用三个月就会变成谁都说不清的黑盒。

1.3 五种通信方案的横向对比

在动手写代码之前，把可选项摆出来对比一下，能省掉后面很多返工。Unity 里常见的模块通信方式大致有五种，各自的适用边界差异很大。

C# 原生event和事件总线的技术底座其实是同一个东西——多播委托。区别在于event是实例级的，你必须持有发布者实例才能订阅；而总线是静态的全局表，任何地方都能发。这也解释了为什么很多人一开始用event，后来项目变大就迁到了总线：跨场景、跨层级的通知用实例事件传不过去。

UnityEvent 的优势在于可视化，策划能在 Inspector 里拖拽绑定，做新手引导、按钮交互这种配置化需求时非常顺手。但它的性能开销比原生委托高一个量级，而且参数类型受限于可序列化类型，做高频事件不合适。我的经验是：面向策划配置的交互用 UnityEvent，面向代码逻辑的模块通信用泛型总线，两者各归其位，别互相替代。

2. 事件中心的核心设计与关键取舍

2.1 用泛型加字典搭一个类型安全的底座

最早的一版事件中心，我见过很多人用字符串当 key：EventCenter.AddListener("player_dead", OnPlayerDead)。写法简单，但问题一大堆。字符串拼错了编译器不管，运行时静默失败；参数只能用一个object，取出来要强转，转错了就是运行时异常；object装箱还会产生 GC，移动端每帧几十次事件就直接体现为卡顿。

正确的做法是用事件类型本身当 key，配合泛型方法。typeof(T)作为字典的键，Action<T>作为值，编译器帮你把类型检查做完了。订阅的时候写EventBus.Subscribe<PlayerDeadEvent>(OnPlayerDead)，发布的时候写EventBus.Publish(new PlayerDeadEvent { ... })，参数类型对不上编译就过不去。这个改动听起来只是写法差异，实际上是把一类运行时错误提前到了编译期，价值非常大。

这里有个细节值得展开：Dictionary<Type, Delegate>的查找性能。Type的GetHashCode在运行时是基于类型句柄计算的，字典查找本身是 O(1)，一次事件分发的固定开销大概在几十纳秒量级，对于每秒几千次的调用完全不是瓶颈。真正的瓶颈在委托链的Invoke和事件结构体的构造上，这两个下面会讲。所以不要为了“性能”去搞什么类型 ID 缓存，收益微乎其微，反而牺牲了可读性。

2.2 为什么坚持用 struct 做事件载荷

事件载荷用 class 还是 struct，是另一个必须做决定的地方。我的答案很明确：默认用 readonly struct，只有在载荷特别大或者需要继承时才用 class。

理由在于 GC。Unity 的托管堆分配会触发垃圾回收，如果事件载荷是 class，每次发布都 new 一个对象，一秒几百次的话，GC Alloc 曲线会非常难看，移动端上表现为周期性的掉帧。用 struct 的话，只要不装箱，分配是零。配合readonly修饰，还能让编译器帮你避免意外修改，因为事件是广播出去的，一个订阅者改了数据会影响后续订阅者，这是典型的隐蔽 bug 来源。

struct 也有它的坑。它是值类型，传递时是拷贝，如果载荷里有引用类型字段（比如GameObject），拷贝的只是引用，指向的还是同一个对象。这不算问题，但要清楚。另外，字段数量建议控制在四到六个以内，再大就该考虑拆成多个粒度更细的事件了。我见过一个GameEvent结构体塞了二十多个字段，什么场景都用它，结果每个订阅者都要从里面挑自己需要的两个字段，可读性极差——这不是 struct 的错，是设计粒度的问题。

注意：事件结构体不要带方法，也不要实现接口，保持它是一份纯数据快照。这样序列化、日志、回放都好处理。

2.3 订阅令牌与生命周期绑定

忘记退订是事件总线第一杀手。一个被销毁的 MonoBehaviour 如果还挂在委托链上，下次发布时就会触发MissingReferenceException，而且这个异常会中断整条链，后面所有订阅者都收不到。更恶心的是编辑器里点开堆栈，看到的是一堆引擎内部代码，根本定位不到是哪个对象忘了退。

最朴素的解决办法是成对写OnEnable订阅、OnDisable退订。这个约定能解决八成问题，但它依赖人，人总会忘。所以我在项目里推的是第二种方案：订阅时返回一个可释放的令牌。

public readonly struct Subscription : IDisposable { private readonly Action _release; public Subscription(Action release) { _release = release; } public void Dispose() { _release?.Invoke(); } }

调用方拿到令牌后using或者存成字段，在OnDestroy里Dispose就完事。这个设计的价值在于它把“退订”从一个需要记住的动作，变成了一个跟随对象生命周期的资源释放动作，心智负担小得多。用readonly struct是为了避免令牌本身在堆上分配，同时防止被意外赋值。

还有一种更激进的方案是弱引用（WeakReference）事件，让总线自己检测目标是否被 GC 回收并清理。听起来很美，实际上手会发现两个问题：委托本身会持有 target 的强引用，你得拆开Target和Method自己维护；而且 Unity 的对象销毁和 C# 的 GC 回收不是同一时机，Destroy之后对象可能还活着好几帧。所以我不推荐在业务代码里用弱引用事件，只在工具链和编辑器扩展里用。

2.4 优先级与执行顺序的设计

多播委托的执行顺序是订阅顺序，这在大多数场景够用，但有些场景必须能控制。典型的例子是伤害结算：护甲减伤必须在外观特效之前执行，否则飘字显示的数值和实际掉血对不上。如果全靠订阅顺序，那就要保证模块初始化顺序，这个在 Unity 里非常脆弱，加个场景加载就可能乱。

所以我在总线的实现里加了优先级参数。内部不再直接存Delegate，而是存一个List<HandlerEntry>，每个 entry 带Priority和Once标志，发布前按优先级降序排一次。排序的稳定性很重要，同优先级的要保持订阅顺序，否则行为不可预期。C# 的List.Sort用的是不稳定的内排序，所以我用OrderByDescending或者在插入时用二分插入保证稳定。

排序本身有开销，但可以优化：只在列表发生变更时标记为脏，发布时如果脏才重排，平时走的是已排好序的数组遍历。这个优化在事件类型多、订阅者多的项目里效果明显，我实测过把一帧内的排序开销从 0.3ms 降到接近 0。不过如果你的项目还在原型阶段，先别做这个优化，直接每次排序也不会有明显感觉，过早优化反而增加维护成本。

2.5 异常隔离与递归保护

多播委托有个特性：链上任何一个回调抛出异常，后面的都不会执行。在事件总线里这是致命的，一个 UI 脚本里的空引用能导致战斗系统的伤害结算整条链断掉，表现形式就是“偶尔不掉血”，排查起来极其痛苦。

解决办法是在发布时把委托链拆成单独的回调逐个调用，每个用 try-catch 包住。Delegate.GetInvocationList()能拿到链上所有回调的数组，代价是有一次数组分配。如果这个分配在热路径上无法接受，可以做两级发布：PublishSafe用于调试和低频事件，PublishFast用于高频事件且约定回调内部自己保证不抛异常。我在项目里默认用安全版，只有在 Profiler 明确指出这里是热点时才换。

递归发布是另一个隐蔽的坑。比如 A 事件的处理逻辑里又发布了 A 事件，如果没有终止条件，就是无限递归直到栈溢出。Unity 的栈溢出报错信息通常很难看，有时连堆栈都给不出。我的做法是在发布入口加一个深度计数器，超过预设层数（比如 8 层）就打印警告并拒绝本次发布。这个检查几乎零成本，但能救命。

提示：递归保护触发时一定要打日志，把当前事件类型和调用栈打出来。静默吞掉会让问题变得更难查。

3. 完整实现：一个能直接落地的 EventBus

3.1 基础骨架代码

先把最小可用版本写出来，这个版本不追求性能极致，但求逻辑清晰、无内存泄漏风险。

using System; using System.Collections.Generic; using UnityEngine; public static class EventBus { private class Entry { public Delegate Callback; public int Priority; public bool Once; } private static readonly Dictionary<Type, List<Entry>> Table = new(64); private static readonly List<Entry> Buffer = new(64); private static readonly List<Action> PendingOps = new(16); private static bool _isPublishing; private static int _depth; public static Subscription Subscribe<T>(Action<T> handler, int priority = 0) { if (handler == null) throw new ArgumentNullException(nameof(handler)); var key = typeof(T); if (!Table.TryGetValue(key, out var list)) { list = new List<Entry>(4); Table[key] = list; } // 重复订阅检测只在编辑器下开，运行时开销为零 #if UNITY_EDITOR foreach (var e in list) { if (e.Callback.Equals(handler)) { Debug.LogWarning($"[EventBus] 重复订阅 {key.Name} -> {handler.Method.Name}"); break; } } #endif var entry = new Entry { Callback = handler, Priority = priority }; list.Add(entry); return new Subscription(() => Remove(key, entry)); } private static void Remove(Type key, Entry entry) { if (!Table.TryGetValue(key, out var list)) return; list.Remove(entry); if (list.Count == 0) Table.Remove(key); } public static void Unsubscribe<T>(Action<T> handler) { var key = typeof(T); if (!Table.TryGetValue(key, out var list)) return; for (int i = list.Count - 1; i >= 0; i--) { if (list[i].Callback.Equals(handler)) list.RemoveAt(i); } if (list.Count == 0) Table.Remove(key); } }

这段代码有两个设计点值得说明。第一，Entry用类而不是结构体，因为它需要被Subscription的闭包捕获并做引用比较，用类更自然，而且 entry 的数量级很小，堆分配可以忽略。第二，Subscription持有的是Entry的引用而不是 handler，这样同一个方法订阅两次也能分别退订，行为更精确。

3.2 加上优先级和一次性订阅

一次性订阅（Once）在真实项目里用得很多，比如“下一帧加载完成时触发一次”这种场景，如果每次都手动退订，很容易漏。实现上就是在发布时检查Once标志，执行完立即从列表移除。

public static void Publish<T>(T evt) { var key = typeof(T); if (!Table.TryGetValue(key, out var list) || list.Count == 0) return; if (_depth > 8) { Debug.LogError($"[EventBus] 事件递归过深，已拦截: {key.Name}"); return; } // 发布期间禁止直接修改列表，先快照 Buffer.Clear(); Buffer.AddRange(list); Buffer.Sort((a, b) => b.Priority.CompareTo(a.Priority)); _isPublishing = true; _depth++; for (int i = 0; i < Buffer.Count; i++) { var entry = Buffer[i]; if (!list.Contains(entry)) continue; // 期间被取消 if (entry.Once) list.Remove(entry); try { ((Action<T>)entry.Callback).Invoke(evt); } catch (Exception ex) { Debug.LogError($"[EventBus] {key.Name} 回调 {entry.Callback.Method.Name} 异常: {ex}"); } } _depth--; _isPublishing = false; }

这里Buffer是一个复用的静态列表，避免每次发布都分配数组。list.Contains(entry)这一步在列表很短时开销可以忽略，但它保证了一个正确性：如果某个回调在执行过程中取消了自己或别人的订阅，后面的回调不会被执行。这个语义我认为比“快照后一律执行”更符合直觉。

_isPublishing标志是为了标记当前处于发布状态，如果此时有新的订阅或退订，理论上应该延迟到发布结束后处理。我上面的实现里已经用list.Contains做了校验，所以官方并不强制要求延迟队列，但如果你追求极致的语义精确，可以引入PendingOps在发布结束后统一 flush。

3.3 安全发布与异常兜底

上面的版本对单个回调做了 try-catch，但logError在高频事件里会成为性能杀手，因为 Unity 的日志输出涉及字符串拼接和堆栈采集。所以我加了一个开关，允许在 Release 包里关闭异常日志，只保留计数器。

public static int ErrorCount { get; private set; } private static void HandleException(string evtName, Delegate callback, Exception ex) { ErrorCount++; #if UNITY_EDITOR || DEVELOPMENT_BUILD Debug.LogError($"[EventBus] {evtName} <- {callback.Method.DeclaringType?.Name}.{callback.Method.Name}\n{ex}"); #endif }

另外要强调一点：Debug.LogError在编辑器里会暂停执行（如果开了 Error Pause），在批量事件场景下会让人以为游戏卡死。所以调试期建议对已知的高频事件用LogWarning或者干脆只计数。我一般会在编辑器里做个面板，把ErrorCount按事件类型分开展示，出问题的时候一眼能看出来是哪个事件在报错。

关于Action<T>的强转，有一点需要确认：如果同一种T上被错误地混入了不同类型的委托（正常流程不会出现），强转会抛InvalidCastException。加个类型检查会更稳妥，但会多一次 is 判断。我的做法是订阅入口做严格类型约束（方法签名已经是Action<T>，编译器保证了），发布端就不再重复检查。

3.4 在 MonoBehaviour 里怎么接

写了一个好的工具，还得有好的使用姿势。我推荐两种接法，按团队习惯选其一。

第一种是令牌式，适合订阅点分散的情况：

public class HealthBar : MonoBehaviour { private Subscription _sub; private void OnEnable() { _sub = EventBus.Subscribe<HealthChangedEvent>(OnHealthChanged); } private void OnDisable() { _sub.Dispose(); } private void OnHealthChanged(HealthChangedEvent e) { // 注意：对象可能已被销毁，事件回调里不要假设自己还活着 if (this == null) return; } }

第二种是集中式，适合一个类订阅多个事件，可以在基类里统一管理：

public abstract class EventBehaviour : MonoBehaviour { private readonly List<Subscription> _subs = new(); protected void Listen<T>(Action<T> handler, int priority = 0) { _subs.Add(EventBus.Subscribe(handler, priority)); } protected virtual void OnDestroy() { foreach (var s in _subs) s.Dispose(); _subs.Clear(); } }

第二种方式在团队里更好推，因为新人写新脚本时只要继承基类，用Listen注册，销毁逻辑自动处理，不需要记住成对写。代价是继承了一个基类，如果项目里已经有别的基类体系可能会冲突。折中方案是做成扩展方法加接口，但那样心智负担反而上升，我倾向于简单直接。

3.5 编辑器里的可视化调试面板

这一节是整个事件总线里我认为最值得投入的部分。总线最大的问题是隐式链路，出问题时你需要在茫茫代码里找谁订阅了谁。解决办法是做一个编辑器窗口，实时显示当前所有事件类型、每个类型下的订阅者列表、回调次数、异常次数。

实现路径不复杂。在Subscribe和Remove里维护一份统计数据（类型名、订阅者声明类型和方法名、调用计数），编辑器窗口用EditorWindow加EditorApplication.update定时刷新即可。列表长的时候用IMGUIContainer或者TreeView做折叠。调用次数可以在Publish里自增，注意这个计数只在编辑器和开发包开启，Release 包用条件编译剔除。

这个面板上线之后，排查效率提升非常明显。有次线上反馈“偶发掉血不掉”，我打开面板一看，DamageEvent的订阅者列表里同一个 UI 脚本出现了两次，回调计数是我们预期的两倍，问题立刻定位到某次OnEnable被重复调用。没有这个工具，光靠断点可能要查半天。

提示：面板里建议加一个“订阅者存活检测”，定时检查UnityEngine.Object类型的 target 是否为 null，为 null 的标红。这是发现泄漏最快的方式。

4. 实战拆解：三个真实场景的接法

4.1 UI与战斗逻辑解耦

先看最常见的 UI 跟随场景。战斗逻辑计算出伤害后，只负责发布一个HealthChangedEvent，里面带上实体 ID、当前血量、最大血量、变化量。UI 层订阅这个事件，判断 ID 是否是自己关心的目标，是则刷新。战斗模块完全不需要引用任何 UI 类，甚至可以放进不引用 UGUI 的程序集。

这个模式的额外好处是支持多表现。同一个事件可以同时被血条、伤害飘字、屏幕震动、音效、成就统计五六个系统消费，逻辑层一行代码都不用改。新加一个表现效果时，只需要新增一个订阅者，这是标准的开闭原则落地。

但要注意一个反模式：别让事件带上 UI 需要的表现参数。比如不要在HealthChangedEvent里加一个Color字段，说“血条要用这个颜色”。事件应该只描述发生了什么，颜色是 UI 自己算的。一旦事件结构体开始承载表现层信息，它就会迅速膨胀，最后变成刚才批评过的那种二十字段的怪物。

4.2 伤害结算链路的顺序控制

伤害结算是个典型的有序需求。我一般把链路拆成四段，用优先级明确控制：

数值怎么定其实不重要，重要的是留出足够的间隔，方便中间插入新的环节。我用 100、90、50、0 这种量级就是给自己留空间，将来要在护甲后面插一个减伤 Buff，用 95 就行，不用动其他代码。

这里有个坑要提醒：高优先级的订阅者如果抛异常，虽然被 try-catch 兜住了，但后续订阅者拿到的是未更新的数据，可能产生不一致。所以关键链路上的回调一定要把异常处理好，不能指望总线兜底。我在项目规范里明确规定：结算类事件的回调内部必须自带完整异常处理，禁止向上抛。

4.3 跨场景的ScriptableObject事件通道

静态事件总线有个天然缺陷：它是全局的，跨场景不清理，切场景时如果没退订干净，旧场景的对象会一直挂在链上。为了解决这个问题，很多团队会引入 ScriptableObject 事件通道，把事件变成资产。

[CreateAssetMenu(menuName = "Events/IntEventChannel")] public class IntEventChannel : ScriptableObject { public event Action<int> Raised; public void Raise(int value) { Raised?.Invoke(value); } private void OnDisable() { Raised = null; // 编辑器下热重载时清理 } }

用资产做事件通道的好处是关系可见：在 Inspector 里把通道资产拖给发布方和订阅方，依赖关系一目了然，比静态总线透明得多。而且场景切换时资产还在，但订阅关系需要各自在OnEnable/OnDisable里维护，行为可预期。

代价是需要创建一堆资产，项目大了之后资产管理会变乱。我的经验是两层并用：跨场景、需要配置化、需要设计师参与的用 SO 通道；同一场景内部的模块通信用静态总线。不要试图用一种方案解决所有问题。

5. 常见问题与排查实录

5.1 内存泄漏：最隐蔽也最致命

泄漏的表现是对象被 Destroy 了，但内存没降，或者下次发布事件时报MissingReferenceException。根因是委托链持有 target 的强引用，只要链还在，GC 就不会回收这个对象。

排查手段有三个层次。第一层是编辑器面板看订阅者列表，红色标记的就是已销毁对象。第二层是在Publish里加检测：如果entry.Callback.Target is UnityEngine.Object obj && obj == null，打印警告并自动移除。第三层是在构建前跑一个检查脚本，扫描所有 MonoBehaviour 的订阅是否都有对应退订。

自动清理这个行为要谨慎。它会让泄漏问题从“报错”变成“静默不生效”，有时候掩盖了更深层的设计问题。我倾向于在编辑器和开发包里自动清理并打日志，正式包里保留日志但照常清理，保证玩家不会因为一个忘退订的 UI 卡死游戏。

5.2 重复订阅与幽灵回调

重复订阅的表现是某个逻辑执行了两次，比如伤害翻倍、音效叠放。根因通常是OnEnable被多次调用（对象池回收复用时很常见），或者父类子类都注册了一次。

OnEnable和OnDisable在 Unity 里不是严格配对的，尤其是对象池场景：禁用时OnDisable触发，重新启用时OnEnable又触发，如果OnDisable里退订失败（比如用匿名 lambda 导致引用对不上），就会重复。所以绝对不要用匿名 lambda 或方法组转换去订阅，因为每次转换都会生成新的委托实例，Equals比较可能失败。要订阅就存一个字段：

private Action<DamageEvent> _handler; private void Awake() { _handler = OnDamage; // 只创建一次 } private void OnEnable() { EventBus.Subscribe(_handler); }

5.3 执行顺序错乱与递归爆栈

顺序问题的表现很微妙：某些情况下数值对得上，某些情况下对不上。前面讲的优先级机制能解决大部分，但有一个盲区——如果两个订阅者优先级相同，顺序取决于订阅时机，而订阅时机又取决于对象创建顺序，这个是运行时决定的，测试环境和线上可能不一致。

所以规范里要写死一条：同一事件上，有数据依赖的订阅者必须给不同优先级。不要依赖默认顺序，哪怕当前看起来是对的。

递归爆栈的表现是游戏直接闪退，日志里可能什么都没有。除了前面说的深度计数器，还要注意一种隐蔽情况：A 事件的处理里修改了某个状态，导致另一个系统发布 A 事件，形成环。这种环在静态代码里几乎看不出来，靠的是日志工具。我在开发包里会给每个事件打上时间戳和调用来源，环形调用会在日志里表现为同一帧内同一事件连续出现多次，很容易识别。

5.4 性能与GC

事件总线的性能开销主要来自三块：字典查找、委托调用、快照列表。前面已经用复用列表优化了快照，字典查找是常数级，剩下的就是委托调用本身。一次Action<T>调用的耗时大约在几十纳秒，一秒一万次也就零点几毫秒，正常情况下不是问题。

真正的性能陷阱在于用事件做每帧高频通信。比如每帧发布一个UpdatePositionEvent让 UI 跟随，这样做在手机上会有明显开销，因为每次都要走完整的发布流程。这种场景应该直接持有引用或者用专门的观察者列表。事件总线适合的是状态变化通知，不是每帧数据同步。

GC 方面，注意两点：一是事件结构体不要装箱，传参时确认泛型参数匹配；二是不要在回调里用闭包捕获局部变量构造新的委托，那会在堆上分配。用 Profiler 的 Deep Profile 模式跑一遍，如果看到EventBus.Publish下面有GC.Alloc，基本就是这两个原因。

5.5 问题速查表

6. 使用边界与团队规范

6.1 这些场景我明确不建议用事件

工具再顺手也不能滥用，有几种场景用事件是纯粹给自己找麻烦。第一种是强父子关系，比如一个子弹预制体里的 Trail 组件需要知道子弹速度，这种一对一、生命周期完全同步的关系，直接GetComponent比事件简洁十倍，用事件反而增加了理解成本。

第二种是需要返回值或同步结果的调用。事件是单向广播，没有返回值。如果你需要“问一下当前血量是多少”，那应该用属性或者方法调用，硬要用事件就得搞一个反向事件，代码会变得极其扭曲。我给团队定的规矩是：事件只用于通知，不用于查询。

第三种是每帧高频数据同步。前面说过，事件适合状态变化，不适合帧级同步。位置同步、动画参数同步这类需求，用引用或者专门的数据绑定组件更合适。

第四种是只有一个消费者的场景。如果某个事件从头到尾只有一个订阅者，那它本质上就是一次方法调用，用事件只是绕了一圈增加复杂度。等真的出现第二个消费者再抽象，不要提前设计。

6.2 落地到团队的三条硬规矩

第一条：事件命名统一用过去式。HealthChanged、ItemPicked、LevelLoaded，一眼能看出这是已经发生的事实，而不是一个可以调用的动作。这条看似是命名规范，实际上影响了整个团队的思维方式：事件是通知，不是命令。

第二条：事件定义集中放在一个程序集里。所有事件结构体放在Game.Events.asmdef中，业务模块引用它，但业务模块之间不互相引用。这样将来拆模块、做热更新、甚至把某些逻辑搬到服务端都会容易得多。这条规矩在项目早期执行成本极低，越晚执行成本越高。

第三条：新增事件必须同时在调试面板里能看见。这听起来像是一句废话，实际执行时会逼着开发者想清楚这个事件的发布者、订阅者、载荷、粒度。我在评审时经常问一句“这个事件谁会订阅”，如果答不上来或者只有一个，那这个事件很可能不该存在。

6.3 一点个人体会

踩过几次坑之后，我对事件总线的态度从“万能解药”变成了“需要谨慎使用的工具”。它确实能解决模块耦合，但代价是运行时的隐式链路。小项目里这个代价不明显，项目一大，如果没有配套的调试工具和团队规范，总线用起来比直接引用还痛苦。

我现在的做法是：项目启动时就把工具链搭好——事件中心、调试面板、日志、结构体定义规范，一次性投入大概一两天，后面能省掉几十个小时的排查时间。另外，我习惯在每次代码评审时专门看一眼新增的订阅有没有配对退订，这个检查花不了十秒钟，但能挡掉大部分泄漏问题。工具是死的，人是活的，真正决定代码质量的还是那几条被反复强调、执行到位的规矩。