做Unity项目做到一定规模，脚本之间的通信会先给你当头一棒。A模块要告诉B模块“玩家升级了”，结果A直接new了一个B的引用，B又反过来持有C的引用，时间一长，场景里挂满了互相缠绕的线，改一个字段能牵连出七八个报错。后来我在实际项目里把这类跨模块通知统一收拢到事件中心（Event Center），那一堆乱七八糟的跨类调用才算理顺。这篇我会分享一种我已经沿用很久的实现方式：底层是字典加泛型委托，配套完整的订阅、发布、注销API，以及MonoBehaviour生命周期里怎么接入才不出事。文章适合已经写过不少Unity逻辑、正在被模块耦合折磨的开发者，也适合刚接触架构设计的同学，我会把每个设计点背后的原因都解释清楚，毕竟只贴代码不给理由的事，做久了容易把人带沟里。
1. 事件中心要解的是什么死结：三个典型场景
1.1 场景一：跨模块的即时通知，不该互相持有引用
拿最经典的“玩家升级”来举例。玩家等级变化之后，UI要刷新等级数字和不变量条，成就系统要检查有没有解锁新勋章，音效系统要播放升级音效，场景里可能还有个宠物系统要跟着触发反馈。如果这些模块都直接引用PlayerController，那PlayerController就得把自己暴露成半个全局类，谁都能拿到它的字段、谁都能改它的状态。更麻烦的是，当一个模块下线、被移出场景时，PlayerController里那个引用就悬在那了，运行的时候越界访问，你能排查半天才发现是某个旧的UI脚本忘记清引用。
用事件中心的写法，发布端只做一件事：把“玩家升级了”这个事实带参数广播出去。至于谁在听、听了之后干什么，发布者完全不关心。UI要不要刷新、音效要不要播、成就怎么处理，那是订阅模块自己的事。模块之间没有直接引用，自然就没有引用悬垂的连锁反应。
1.2 场景二：一对多广播，静态事件也能做但容易失控
有人会问，C# 本身就有 event Action，定义一个静态事件，在任意模块里 += 不也是一对多广播吗？这确实能用，但项目里的模块一多，你会收获几十个散落在各处的 public static event。没有统一的目录，没有统一的注销约定，每次找“某个事件是谁定义的”都要靠IDE搜变量名，事件多了之后连事件本身都成了全局垃圾场。
事件中心的价值不是发明了一种新机制，而是把这些事件登记、订阅、发布、注销全部集中到一个容器里。事件类型用枚举统一管理，订阅入口、发布入口都是同一个API，后面想加日志、加延迟发布、加故障隔离，都有统一的下手点。这一点的实际收益比你想象中大，我见过不少项目因为静态事件散落各处，最后排查事件泄漏要检查几十个类。
1.3 场景三：模块可以随时上下线，而不用回头改发布端
在一款大厅加商城、加活动、加成就的框架里，模块的加载和卸载是动态的。没有事件中心时，新增一个接收模块意味着去改了发布者的代码，加一个调用；把这个模块去掉时，又得回来删调用。一次两次还好，迭代多了，发布者代码变得越来越大，职责越来越杂。
事件中心让发布端完全不感知接收端存在。接收模块在活动状态时订阅好，发布者发一次消息，它就能收到；模块被移除了，只要注销按时做，发布者代码一个字都不用动。这种“新增功能只写在新增模块里”的效果，才是解耦真正想达到的状态。
1.4 边界：事件中心不适合有返回值的请求
事件中心是广播模型，不是请求—响应模型。如果你需要“让装备工厂生成一把武器并且立刻拿到这把武器的实例”，这不该走事件，应该用接口或者直接方法调用。事件天生是单向通知，发布出去的回调没有返回值，所有试图在事件里拿返回结果的设计都属于玩偏了。能用事件解决的，是通知和反馈，不是调用链本身。
2. 为什么是“字典 + 泛型委托”而不是其他套路
2.1 先看几种常见方案的实际差距
很多团队一开始会用最顺手的方式，但顺手不等于合适。我把常见的几个方案拉了一张对比表，你可以对照自己的项目阶段看：
| 方案 | 优点 | 缺点 |
|---|---|---|
| 静态事件 | 写法简单，编译器可以检查 | 生命周期分散，事件名称散落，无法统一管理，容易泄漏 |
| UnityEvent | 可在Inspector里拖拽配置 | 不适配动态生成的物体，跨模块引用配置麻烦，强类型能力弱 |
| ScriptableObject事件通道 | 资源化配置，策划可调 | 每个事件都要建资产文件，模块多了之后资产数量爆炸 |
| 静态类 + 字典 + 泛型委托 | 集中管理，类型安全，容易扩展日志队列 | 全局状态，必须约定好生命周期规范 |
我最终选的是静态类加字典的方案，因为它在集中管理、类型安全和扩展性上最均衡，而且不依赖编辑器配置，代码里写清楚就能跑。
2.2 用枚举做事件类型，是给消息立户口
事件类型用什么当键，这是个很容易被忽略的决策。用字符串的话，调用的时候写Subscribe("OnPlayerLevelUp")和Publish("OnPlayerLevelUp")，一旦拼错一个字母，编译器不会报错，你只会发现某个模块莫名其妙收不到消息，最后查半天发现字符串多了个空格。字符串重构也很难做，事件名散落在代码里，重命名要靠全局替换。
用枚举当键，等于给所有事件立了一个统一户口：所有可能的事件类型在GameEventType这个枚举里一目了然，代码里写错枚举名，编译阶段就报错了。新加事件只需要改一次枚举定义，IDE的自动补全还能帮你列出来。代价是每次加事件都要编译一次，但这点代价换来的是集中可搜索、编译器可检查，非常值。
2.3 字典是类型安全的注册表
字典的Key是GameEventType，Value存什么这是个关键选择。我存的是Delegate而不是Action或者Action<object>。为什么是Delegate基类？因为同一个字典里既要有无参的Action，也要有带任意参数的Action<T>，这两者的具体类型不同，只有它们的公共基类Delegate能把它们统一放进去。
具体到参数传递，我更反对Action<object>的做法。用object意味着发布时要把数据装箱，订阅时还要自己拆箱强转，你写的时候知道自己传的是 int 还是 class，但类型系统已经帮不上忙了，错一次就是运行时异常。泛型Action<T>能在编译期保留参数类型：发布PlayerLevelUpData时，订阅者的方法签名必须是void OnPlayerLevelUp(PlayerLevelUpData data)，类型不对编译器直接报错。这是整套方案的可靠性根基。
2.4 一个事件号只对应一种回调签名，这是铁律
因为 Value 类型是Delegate，无参的Action和带参的Action<T>可以同时存活在字典里，但同一个事件号绝不能同时绑定不同的回调签名。比如PlayerLevelUp这个事件号，你订阅时用了Action，另一个人订阅时用了Action<int>，字典里同一个键下面就会混入两种委托。发布的时候我是按Action<int>去强转，还是按Action去强转？无论按哪个转，都有一个订阅者永远收不到消息。
这个限制不是缺陷，而是设计上必须立住的规矩。我在Subscribe方法里做了一个显式检查：如果同一个事件号已经存在了不同签名的委托，直接抛异常，让错误尽早暴露在开发阶段，而不是线上发布之后才静默失效。
3. 事件中心的完整实现与核心代码解读
3.1 事件号目录：GameEventType 枚举
先定义一个枚举当作所有事件的身份ID。实际项目里可以按模块分段，用注释分隔：
using System; namespace GkFramework { public enum GameEventType { // 玩家相关 PlayerLevelUp = 1, PlayerGoldChanged = 2, PlayerHealthChanged = 3, // 玩法相关 ComboChanged = 4, GameStateChanged = 5, WaveStarted = 6, WaveFinished = 7, // 系统相关 InventoryChanged = 8, AchievementUnlocked = 9 } }枚举值从1开始，用0作为None = 0的占位值，可以避免默认值误触事件。具体事件按模块分段落，以后新增事件只需在对应段落追加。
3.2 EventCenter 主体
事件中心本身是一个静态类，不继承MonoBehaviour。因为它是一个纯注册表，不需要在场景里挂物体，也不需要实例状态，静态类最直接。如果项目里搞热重载或者多场景管理需要重置，我提供了一个Clear()方法。
using System; using System.Collections.Generic; using UnityEngine; namespace GkFramework { public static class EventCenter { private static readonly Dictionary<GameEventType, Delegate> _listeners = new Dictionary<GameEventType, Delegate>(); // 日志开关，只在开发构建下生效 #if UNITY_EDITOR || DEVELOPMENT_BUILD public static bool EnableLog = true; #else public static bool EnableLog = false; #endif // ---------- 订阅 ---------- public static void Subscribe<T>(GameEventType eventType, Action<T> callback) { TrySubscribe(eventType, callback); } public static void Subscribe(GameEventType eventType, Action callback) { TrySubscribe(eventType, callback); } private static void TrySubscribe(GameEventType eventType, Delegate callback) { if (callback == null) { throw new ArgumentNullException(nameof(callback), "订阅事件时不能传空回调"); } if (_listeners.TryGetValue(eventType, out var existing)) { if (existing.GetType() != callback.GetType()) { throw new InvalidOperationException( $"[EventCenter] 事件 {eventType} 已注册了 {existing.GetType().Name}，" + $"不能再注册 {callback.GetType().Name}，一个事件号只能绑定一种回调签名。"); } // 先移除再合并，避免重复订阅同一个方法导致回调被调用两次 var removed = Delegate.Remove(existing, callback); _listeners[eventType] = removed == null ? callback : Delegate.Combine(removed, callback); } else { _listeners[eventType] = callback; } if (EnableLog) { Logger.Log($"[EventCenter] {GetOwnerName(callback)} 订阅了事件 {eventType}，回调 {callback.Method.Name}"); } } // ---------- 注销 ---------- public static void Unsubscribe<T>(GameEventType eventType, Action<T> callback) { TryUnsubscribe(eventType, callback); } public static void Unsubscribe(GameEventType eventType, Action callback) { TryUnsubscribe(eventType, callback); } private static void TryUnsubscribe(GameEventType eventType, Delegate callback) { if (callback == null) return; if (!_listeners.TryGetValue(eventType, out var existing)) return; var removed = Delegate.Remove(existing, callback); if (removed == null) { _listeners.Remove(eventType); } else { _listeners[eventType] = removed; } } // ---------- 发布 ---------- public static void Publish<T>(GameEventType eventType, T arg) { if (!_listeners.TryGetValue(eventType, out var entry)) return; if (entry is Action<T> handler) { InvokeSafely(handler, arg, eventType); } else { Debug.LogError($"[EventCenter] 事件 {eventType} 的回调签名不匹配，" + $"已注册的是 {entry.GetType().Name}，发布时却使用了 Action<{typeof(T).Name}>。"); } } public static void Publish(GameEventType eventType) { if (!_listeners.TryGetValue(eventType, out var entry)) return; if (entry is Action handler) { InvokeSafely(handler, eventType); } else { Debug.LogError($"[EventCenter] 事件 {eventType} 的回调签名不匹配，" + $"已注册的是 {entry.GetType().Name}，发布时却使用了 Action。"); } } // ---------- 故障隔离 ---------- private static void InvokeSafely<T>(Action<T> handler, T arg, GameEventType eventType) { var invocationList = handler.GetInvocationList(); for (int i = 0; i < invocationList.Length; i++) { try { ((Action<T>)invocationList[i]).Invoke(arg); } catch (Exception ex) { Debug.LogError($"[EventCenter] 处理事件 {eventType} 时，回调 " + $"{invocationList[i].Method.Name} 抛出异常：\n{ex}"); } } } private static void InvokeSafely(Action handler, GameEventType eventType) { var invocationList = handler.GetInvocationList(); for (int i = 0; i < invocationList.Length; i++) { try { ((Action)invocationList[i]).Invoke(); } catch (Exception ex) { Debug.LogError($"[EventCenter] 处理事件 {eventType} 时，回调 " + $"{invocationList[i].Method.Name} 抛出异常：\n{ex}"); } } } // ---------- 工具 ---------- public static void Clear() { _listeners.Clear(); } private static string GetOwnerName(Delegate callback) { if (callback.Target is UnityEngine.Object unityObject) { return unityObject.name; } var targetType = callback.Target?.GetType(); return targetType == null ? "静态方法" : targetType.Name; } } }3.3 关键设计点逐一解读
先看字典的选择：Dictionary<GameEventType, Delegate>并不是性能最优的方案，但它是工程上最平衡的。事件注册和注销不是每帧都在跑的热点逻辑，字典的 O(1) 查找完全够用。真正要关注的是Delegate.Combine和Delegate.Remove，这两个方法会生成新的委托链，在频繁注册和注销时会产生一些托管分配，但对一个对象生命周期内的订阅次数来说，量级可以忽略。
Subscribe里“先 Remove 再 Combine”是我后来补的一个细节。一开始我用的是直接Delegate.Combine(existing, callback)，结果某几个模块在OnEnable和Awake里各订阅了一次，同一事件被回调了两遍，排查了很久才发现是重复注册。现在直接内部去重，外部就算调用方自己写得不规范，事件中心也能兜住，不会出现同一个方法在委托链里挂两份的情况。
Publish里的entry is Action<T> handler其实是一个模式匹配强转。如果有人在订阅时用了Action，发布时却用Action<T>，这里entry不是Action<T>类型，我不会让程序崩溃，而是打一条明确的错误日志。你要是在别的地方遇上“事件发布了但没人响应”的怪问题，多半就是这个原因，这条日志能帮你第一时间定位。
带异常的InvokeSafely版本，我建议在开发和测试阶段一直用。它逐个调用监听链上的回调并加 try-catch，保证一个订阅者抛异常不会影响后面所有订阅者。代价是GetInvocationList()会在发布时分配一个委托数组，在高频发布、要求极致性能的场景下可以换用直接handler.Invoke(arg)，但那是优化阶段的事，刚开始不要为了省这一点性能丢掉故障隔离。
3.4 字符数之外的几个隐藏细节
这段代码里藏的#if UNITY_EDITOR || DEVELOPMENT_BUILD编译指令也很重要。开启日志后，每次订阅和发布都会打点日志，这在开发期是救命稻草；到了发布版本，直接关闭，日志开销归零。发布版附带的日志不仅影响性能，还很占内存，别让它在线上版本里开着。
GetOwnerName这个方法是我自己后来加的。所有订阅回调的callback.Target里都藏着订阅者对象本身，如果这个对象是UnityEngine.Object，就能拿到场景里的物体名。这样日志里能直观看到“哪个场景物体订阅了哪个事件”，排查悬垂订阅时信息量直接翻倍。
4. MonoBehaviour 里怎么接入：订阅与注销的生命周期闭环
4.1 一个完整的接入演示
我设计一个最小可跑的演示：玩家升级，UI刷新、成就检查、音效播放三个模块同时响应。定义事件参数：
using System; namespace GkFramework { public struct PlayerLevelUpData { public int Level; public int MaxHp; public float Timestamp; } }发布端很简单：
using UnityEngine; namespace GkFramework { public class PlayerController : MonoBehaviour { private int _level = 1; public void LevelUp() { _level++; PlayerLevelUpData data = new PlayerLevelUpData { Level = _level, MaxHp = 100 + _level * 10, Timestamp = Time.time }; EventCenter.Publish(GameEventType.PlayerLevelUp, data); } } }接收端每个模块都遵循同一套生命周期契约：
using UnityEngine; namespace GkFramework { public class UIManager : MonoBehaviour { private void OnEnable() { EventCenter.Subscribe(GameEventType.PlayerLevelUp, OnPlayerLevelUp); } private void OnDisable() { EventCenter.Unsubscribe(GameEventType.PlayerLevelUp, OnPlayerLevelUp); } private void OnPlayerLevelUp(PlayerLevelUpData data) { // 刷新等级显示、血条上限等 Debug.Log($"UI 收到升级事件，当前等级 {data.Level}"); } } }成就系统和音效系统的写法完全一样，只是各自处理自己的逻辑。发布者不需要知道这三个接收者是谁，接收者也不需要互相认识。
4.2 用 OnEnable 订阅、OnDisable 注销，而不是 Awake 和 OnDestroy
很多初学者习惯在Awake订阅、在OnDestroy注销，这在单个物体的生命周期里没问题，但换到对象池和场景切换的场景，就会出乱子。对象池里的物体在回收时未必走OnDestroy，它只是被SetActive(false)；场景切换时物体被销毁前会依次执行OnDisable再到OnDestroy。如果你只写了OnDestroy注销，前面还有一大段禁用时间，物体是禁用状态，但订阅还挂在那里，事件照常广播给它，会在禁用物体里触发一堆空引用。
所以我的约定是：OnEnable订阅，OnDisable注销。物体被禁用、被回收、被销毁，都会走到OnDisable，注销时机跟着这个生命周期走，天然覆盖所有情况。这个惯例推行之后，我再没遇到过场景切换后事件打到已销毁物体上的悬垂问题。
如果你担心某个模块在禁用状态下仍然需要接收事件，我建议你重新审视设计：一个已经被禁用、UI都已经隐藏的模块，真的需要响应玩家升级吗？让它在禁用状态下继续做事，反而容易制造隐藏分支和意向不到的副作用。保持简单，禁用即退订，是这套方案里我最推荐的一条规则。
4.3 事件参数不要裸奔：一个事件一个数据对象
事件参数最怕写成Action<int, int, float>这种裸奔签名。一开始你可能觉得参数不多，直接传三个值挺方便；但需求一迭代，等级提升要附带一个“是否来自特殊道具”的标记，你就得把第二个参数硬插进去，所有订阅者签名都要跟着改。改签名一次两次能忍，次数多了就等着哭。
我给每个事件准备一个专用数据对象，上面代码里的PlayerLevelUpData就是例子。参数对象的好处是加字段不影响订阅者签名，新加字段时旧订阅者可以完全无视它；也让发布时看起来像一个完成的“消息包”，而不是好几个零散数值在空中飞。用struct还是class，我的经验是：参数对象比较简单、只有几个值类型字段时用struct减少堆分配；一旦里面有string、List、Texture这种引用类型，或者对象经常被修改，就直接用class，避免在传参过程中反复拷贝造成误解。
5. 实战排雷：订阅泄漏、重复注册、参数错配这些坑
5.1 重复订阅导致回调被执行两次
重复订阅是我在这个事件中心方案里踩到的第一个坑。起因是一个模块在Awake里订阅了一次升级事件，又在OnEnable里订阅了一次，两个方法都引用同一个事件处理方法，委托链上挂了同一个方法两份，玩家每次升级，UI 代码跑两遍，金币计数翻倍。
这个问题的根源在于Delegate.Combine本身不感知“同一个方法的同一个实例是否已经存在”，它严格按规则把委托链加长。解决办法有两个：一个是让调用方强制遵守“先注销再订阅”，另一个是在Subscribe内部先Remove再Combine，我在上面的代码里就是这么处理的。第二种方案虽然每次订阅多了一次 Remove 操作，但换来了全局规范兜底，我强烈建议事件中心内部做这个去重，不要指望每个人写代码时都自律。
5.2 场景切换和对象销毁后的悬垂订阅
静态字典不会被场景切换自动清空，这是所有静态容器类工具的共同特点。你切换到下一个场景，旧的场景物体被销毁了，但字典里还挂着那些物体方法。之后发布事件，Unity 会在调用回调方法内部访问transform、字段的时候抛MissingReferenceException，因为它拿到的引用对象已经没了。
很多团队面对这个问题的第一反应是在事件中心里做弱引用，让监听器被GC之后自动清理。但Unity里这套往往不灵，因为MonoBehaviour的“销毁”是由引擎管理的，不立即触发托管GC；就算你用的WeakReference也只能等MonoBehaviour被GC回收之后才失效，这个时间点远远晚于场景切换那一刻。引擎上的Destroy只是把对象标记为待销毁，托管侧引用还活着的时候，WeakReference 里仍然能看到它。
所以我最终的结论是：不要依赖弱引用，老老实实按OnDisable注销的契约来。只要每个订阅的 MonoBehaviour 都写了OnEnable订阅和OnDisable注销，场景切换时所有物体被禁用和销毁前都会执行OnDisable，字典自动清理，不存在悬垂引用。事件中心的核心维护成本不在代码，而在团队对这个生命周期契约的执行力。
5.3 发布时的参数类型不匹配，为什么会静默丢失
调用Subscribe<int>(GameEventType.PlayerLevelUp, OnLevelUp)然后Publish<string>(GameEventType.PlayerLevelUp, "hello")，编译不会报错，因为这两个泛型方法各自推断自己的T，彼此不联动。到了运行期，发布时我尝试把字典里的委托强转为Action<string>，转不过去，事件就被丢弃了。
这种问题最讨厌的一点是表面看起来什么都没发生：没有异常、没有崩溃，只有那个模块没反应。排查时你往往先怀疑是不是没订阅、是不是生命周期问题，最后才能想到参数类型错了。所以我在Publish里特意打了一条Debug.LogError，只要签名不匹配就立刻报出来。开发阶段看见红色日志总比线上静默丢事件强一百倍。要彻底防住，最有效的办法还是那个数据对象规范：每个事件都对应一个唯一的数据类，领域模型里的大象和老鼠不会搞混。
5.4 回调链里一个异常会干掉后面的所有监听
假设三个模块订阅了同一个事件，第一个订阅者在回调方法里访问了一个空引用然后抛了异常。如果用直接的handler.Invoke(arg)，这行代码抛出异常后，后面的两个订阅者全都会被跳过。这种交互方式很隐蔽，你只看到一个模块没反应，实际上另外两个模块也跟着遭殃了。
这就是为什么我在Publish里改成逐个GetInvocationList()再 try-catch 调用。每个订阅回调的异常都只会影响它自己，其他监听者照样收得到消息。代价我已经说过是分配一个委托数组，所以我给了个开放的选择：如果某个事件在你的项目里每秒触发几十上百次，而且你确认所有订阅者的回调都稳健到不可能抛异常，那可以给那个事件单独做快速路径，直接用Invoke；其他绝大多数事件都走安全链路。这个权衡值得做，但放到性能测试阶段再决定也不迟。
6. 从够用到好用：延迟发布、日志追踪、弱引用的再讨论
6.1 延迟到下一帧发布：用闭包队列替代消息对象
做战斗系统的时候会经常遇到这种需求：玩家攻击命中，先让伤害飘字滚动，再等攻击动画播完触发后续逻辑，中间的状态变化需要在下一帧才通知其他模块。直接在触发位置同步发布事件，订阅者会立刻执行，打乱了预期顺序。
我给事件中心加了一个延迟发布入口，用闭包队列实现：
using System; using System.Collections.Generic; using UnityEngine; namespace GkFramework { public static partial class EventCenter { private static readonly Queue<Action> _delayedQueue = new Queue<Action>(); public static void PublishNextFrame(GameEventType eventType) { _delayedQueue.Enqueue(() => Publish(eventType)); } public static void PublishNextFrame<T>(GameEventType eventType, T arg) { _delayedQueue.Enqueue(() => Publish(eventType, arg)); } public static void FlushDelayed() { while (_delayedQueue.Count > 0) { var action = _delayedQueue.Dequeue(); try { action(); } catch (Exception ex) { Debug.LogError($"[EventCenter] 延迟发布事件执行异常：\n{ex}"); } } } } }用一个驱动器在帧末统一刷新：
using UnityEngine; namespace GkFramework { public class EventCenterDriver : MonoBehaviour { private void LateUpdate() { EventCenter.FlushDelayed(); } } }这里用闭包而不是存消息对象，最大的好处是闭包天然携带了事件类型和参数对象，不需要反射也不需要序列化。延迟到FlushDelayed()时才执行Publish，数据在闭包里待一个帧生命周期，够用也不算浪费。需要注意的是：延迟发布队列是全局状态，如果你在某个场景里上了多个驱动器，要确保只有一个在运行，否则队列会被重复刷新。我一般把这个驱动脚本挂在一个DontDestroyOnLoad的常驻物体上。
6.2 谁订阅了什么：从回调Target里挖出订阅者
事件中心最大的缺点之一就是调用链隐性化，出了 bug 很难追踪谁订阅了谁、谁发布的。日志开关是我排查的秘密武器：订阅和发布都打点，日志里带上订阅者对象的名字和方法名。
上面GetOwnerName(callback)这个方法的核心就是callback.Target。Delegate的Target属性会返回承载这个实例方法的对象，如果是 MonoBehaviour，就能直接拿到它的name；如果是静态方法，Target 是 null，我们就打上“静态方法”标记。配合编译开关，开发阶段打开日志，你完全可以看到“Player 物体订阅了 PlayerLevelUp”这类信息；发布版一关，这一整套日志开销直接消失。
6.3 弱引用到底该不该用
前面讲悬垂订阅的时候我提了一嘴，这里展开说。网上很多事件系统的教程都会提供一个 WeakReference 版本，号称“自动清除已被销毁的监听器”，我实际测试过之后可以负责任地告诉你：在 Unity 里这条路行不通，至少不能作为保底方案。
原因在于Destroy(obj)只是让对象在引擎层失效，托管侧的 C# 对象仍然活着，直到 .NET GC 真正回收它；而事件中心这类静态容器又是根，挂在里面的委托不会让对象被 GC 更早回收，反而因为委托引用，对象从非根变成了根可达，GC 根本不会回收它。WeakReference 包装之后，确实解除了根可达性，但引擎层的“已销毁”状态并不会立刻触发 GC，你把这个对象Destroy了，它的托管内存还在，WeakReference 里还是能够看到目标，直到某次 GC 真的发生。这中间你把事件发布出去，回调里访问transform照样报MissingReferenceException。所以在 Unity 里，可靠的生命周期管理永远是第一位的，弱引用只适合作为“对象被 GC 后兜底移除”的辅助手段，不能反过来依赖它做主力防线。
6.4 性能说明和更极端的替代方案
最后聊一下这套方案的上限。每个事件订阅其实是一个委托链节点，发布时通过字典找到链再遍历调用，复杂度 O(n)，n 是订阅数量。大多数游戏事件，订阅数量是两位数以内，开销完全可以忽略。每个发布事件在故障隔离模式下会分配一个委托数组，这也是个别事件可以换快速路径的理由。
如果哪天真的遇到性能瓶颈，其中一种极端做法是把枚举事件映射到数组索引——因为枚举本质是 int，如果事件类型从 0 开始连续递增，可以直接Action<T>[] _events = new Action<T>[最大枚举数]，用索引代替字典，查询速度和内存占用都会更好，代价是枚举定义不能随意插队，否则索引就错位了。还有一种方式是手写循环链表式的事件槽代替委托链，减少 Combine/Remove 的字符串拼接和分配。不过这些都是先量化再优化的阶段该做的事。我见过很多团队还没上线就在纠结这种微观性能，结果代码写了一堆难维护的轮子，实际帧耗时根本没有变化。事件中心先做到代码清晰、生命周期规范、日志可用，已经能解决绝大多数项目的问题，性能是等你真正拿到 Profiler 数据之后再谈的事。
