事件订阅导致内存泄漏是因为事件源对订阅者的处理方法持有强引用，使订阅者无法被GC回收；WeakEventManager通过弱引用解决此问题，但高频或需强保证的场景不适用。
为什么事件订阅会导致内存泄漏
在 C# 中，事件本质上是多播委托（MulticastDelegate），当对象 A 订阅对象 B 的事件时，B 会持有一个指向 A 中处理方法的强引用。只要 B 没被释放，A 就无法被 GC 回收——哪怕 A 的业务逻辑早已结束。典型场景如：UI 控件订阅 ViewModel 事件、后台服务订阅长时间存活对象的事件。
这种泄漏不易察觉，尤其在 WPF/WinForms 中反复创建/销毁视图时，内存占用持续上涨却无明显异常。
WeakEventManager 是最稳妥的内置方案
WeakEventManager 是 WPF 提供的、专为解决 UI 层事件内存泄漏设计的弱事件管理器。它不持有事件处理者的强引用，允许处理者被 GC 正常回收。
使用要点：
- 必须继承
WeakEventManager并实现StartListening/StopListening - 事件源（sender）需支持
INotifyPropertyChanged或自定义事件（如PropertyChanged、CollectionChanged） - 推荐用泛型静态类封装，避免重复注册：例如
PropertyChangedEventManager.AddHandler - WPF 之外（如 .NET Core Console 或 Blazor）默认不可用，需手动引入
PresentationCore引用
示例（监听 INotifyPropertyChanged）：
PropertyChangedEventManager.AddHandler(source, handler, "PropertyName");
触发后若 handler 所属对象已回收，该监听自动失效，不会 crash。
手动实现 WeakReference + EventHandler 的轻量方案
对非 WPF 环境或需要完全可控的场景，可基于 WeakReference<t></t> 自建弱事件包装器。核心是：不把 handler 直接存进事件委托链，而是通过弱引用来间接调用。
关键实现细节：
- 用
WeakReference<action></action>或WeakReference<object></object>+ 反射调用，但后者性能差；推荐前者配合闭包捕获 - 每次触发前必须先
TryGetTarget(out action)，为 null 则自动从内部列表移除 - 事件订阅方法（如
Subscribe）应返回IDisposable，便于显式清理残留项 - 避免在
Finalize或终结器中操作事件，GC 不保证执行时机
简化的订阅结构示意：
public class WeakEvent<TEventArgs>
{
private readonly List<WeakReference<Action<object, TEventArgs>>> _handlers = new();
public void Subscribe(object subscriber, Action<object, TEventArgs> handler) {
_handlers.Add(new WeakReference<Action<object, TEventArgs>>(handler));
}
public void Raise(object sender, TEventArgs e) {
_handlers.RemoveAll(wr => !wr.TryGetTarget(out var h) || h == null);
foreach (var wr in _handlers.ToList()) {
if (wr.TryGetTarget(out var h)) h(sender, e);
}
}
}哪些情况不适合用弱事件
弱事件本质是“放弃对订阅者的生命周期控制”，因此以下场景要格外谨慎：
- 事件处理逻辑必须严格保证执行（如资源清理、状态同步），而弱引用可能在触发前已被回收
- 高频触发事件（如鼠标移动、渲染帧回调），频繁
TryGetTarget和列表遍历带来额外开销 - 跨线程访问未加锁的弱引用集合，可能引发
InvalidOperationException或漏触发 - 处理方法是静态方法或 lambda 闭包捕获了长生命周期对象，导致弱引用失效（实际仍强引用）
真正安全的弱事件，依赖的是「处理者自身可被及时回收」这一前提。如果对象本就该长期存活，那问题不在事件，而在设计本身。
