为什么事件订阅会导致内存泄漏
在 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.AddHandlerWPF 之外（如 .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 闭包捕获了长生命周期对象，导致弱引用失效（实际仍强引用）
真正安全的弱事件，依赖的是「处理者自身可被及时回收」这一前提。如果对象本就该长期存活，那问题不在事件，而在设计本身。
