直接用 event 不够用，因其强耦合：发布者需知订阅者类型与实例，且限于同生命周期；而事件聚合器通过弱引用、泛型消息和线程安全设计实现松耦合跨层通信与自动清理。
为什么直接用 event 不够用？
因为 event 是强耦合的：发布者必须知道订阅者的类型和实例，且只能在同一个对象生命周期内绑定。实际项目中，模块间往往需要跨层通信（比如 ViewModel 通知 Service 层刷新数据），或临时订阅后自动清理（避免内存泄漏）。这时候硬写 += 就会埋下隐式引用、难以解绑、测试困难的坑。
真正需要的是“发布时不关心谁收，订阅时不关心谁发”的松耦合机制——也就是事件聚合器（Event Aggregator）。
WeakReference 是解决内存泄漏的关键
多数手写 Pub/Sub 最终崩在内存泄漏上：UI 控件订阅了全局事件，但控件销毁后没手动 -=，导致整个控件对象被事件源强引用而无法 GC。
正确做法是让订阅者以弱引用方式注册：
public class EventAggregator
{
private readonly ConcurrentDictionary<type list>>> _handlers = new();
<pre class="brush:php;toolbar:false;">public void Subscribe<T>(Action<T> handler)
{
var type = typeof(T);
var weakHandler = new WeakReference<Delegate>((Delegate)handler);
_handlers.GetOrAdd(type, _ => new()).Add(weakHandler);
}
public void Publish<T>(T message)
{
if (_handlers.TryGetValue(typeof(T), out var refs))
{
for (int i = refs.Count - 1; i >= 0; i--)
{
if (refs[i].TryGetTarget(out var d) && d is Action<T> action)
action(message);
else
refs.RemoveAt(i); // 自动清理已回收的订阅
}
}
}
}
注意点：
- 必须用
ConcurrentDictionary和List<weakreference>></weakreference>，不能用普通Dictionary+EventHandler - 遍历时要倒序删（
i--），否则删中间项会跳过下一个 -
TryGetTarget返回false时立刻移除，否则下次仍会遍历无效引用
如何支持泛型消息 + 多类型同时监听？
别用 object 做基类传参，那会丢失类型信息、强制转型、无法编译期校验。真正的高级用法是靠泛型约束和消息继承树：
public interface IEvent { }
public class UserLoggedInEvent : IEvent { public string UserId { get; } }
public class DataLoadedEvent<t> : IEvent { public T Data { get; } }
<p>// 订阅时可精确到子类
aggregator.Subscribe<userloggedinevent>(e => Console.WriteLine(e.UserId));
aggregator.Subscribe<ievent>(e => LogAllEvents(e)); // 也能监听所有事件</ievent></userloggedinevent></p></t>
关键设计逻辑：
- 所有消息实现
IEvent，方便统一管理但不牺牲类型安全 - 订阅
IEvent要比订阅具体类型慢一点（多一层虚调用），但换来的是调试时能抓全流量 - 如果用
typeof(T).IsAssignableFrom(typeof(IEvent))做运行时校验，就破坏了泛型优势，别这么干
线程安全边界在哪？
Publish 必须是线程安全的，但 Subscribe 和 Unsubscribe 不一定需要实时同步——大多数场景下，订阅动作本身发生在初始化或 UI 线程，极少并发修改。所以：
- 用
ConcurrentDictionary+List组合已足够应对绝大多数并发发布场景 - 不要给
Subscribe加锁，否则初始化慢、容易死锁（比如两个模块互相等待对方完成订阅） - 如果真遇到高并发订阅（如插件热加载），改用
ReaderWriterLockSlim控制写入，读取路径保持无锁 - 所有回调都在发布线程同步执行，不自动切线程——这是故意的：避免隐藏的调度开销和上下文丢失（比如
SynchronizationContext）
真正复杂的地方永远不是怎么发消息，而是消息语义是否清晰、生命周期是否可控、以及错误时有没有 fallback 通道。比如 Publish 内部抛异常，是否该吞掉？要不要提供 TryPublish？这些得看你的业务容错等级，不是模式本身能决定的。
