1. 从“委托”到“事件”为什么我们需要这个“包装器”如果你已经跟着上一篇内容把C#委托的来龙去脉搞清楚了那你可能会有一个疑问委托本身已经能很好地实现方法的间接调用和回调了为什么还要多出一个“事件”的概念这不是把简单问题复杂化了吗我刚开始学的时候也是这么想的总觉得事件就是委托的一个“马甲”直到在实际项目中踩了几个大坑才彻底明白微软设计“事件”这个语法糖的良苦用心。简单来说事件是对委托的一种封装和约束它的核心目标是解决一个在面向对象编程中至关重要的问题封装与安全。想象一个场景你写了一个温度传感器类TemperatureSensor它内部有一个委托字段OnTemperatureChanged用来通知外部温度发生了变化。如果这个字段是public的那么任何使用你这个类的代码都可以直接对这个委托做三件“危险”的事情直接赋值 ()后来的订阅者会直接把先前的订阅者全部覆盖掉。随意调用外部代码可以随时、随地、以任何参数触发这个“通知”完全绕过了TemperatureSensor类内部的逻辑控制。清空所有订阅 ( null)这会导致所有监听者都收不到通知系统行为变得不可预测。这就像你把家里大门的钥匙复制了好几份随便发给邻居和朋友。他们不仅可以进来订阅还可以换掉你的锁赋值甚至在你不在家的时候以你的名义开派对随意触发。这显然违背了类的“封装”原则——类的内部状态和通知机制应该由类自己来管理。事件Event就是为了解决这个问题而生的。你可以把事件理解为一个对委托进行了访问限制的“属性”。对于事件的发布者比如TemperatureSensor来说它在类内部看到的还是一个完整的委托可以自由地添加/移除响应方法并在合适的时机触发它。但对于类的外部订阅者来说他们只能看到两个操作订阅和-取消订阅。他们既不能直接赋值也不能直接触发这个事件。用代码来对比一下就很清晰了// 使用公共委托字段 - 不安全 public class TemperatureSensor_Unsafe { public Actionfloat OnTemperatureChanged; // 公共委托字段 public void ReadSensor() { float temp ReadFromHardware(); // 外部代码可以直接sensor.OnTemperatureChanged null; 或者 sensor.OnTemperatureChanged?.Invoke(999); OnTemperatureChanged?.Invoke(temp); } } // 使用事件 - 安全 public class TemperatureSensor_Safe { // 声明一个事件。这里底层仍然是一个委托但对外的接口被限制了。 public event Actionfloat TemperatureChanged; public void ReadSensor() { float temp ReadFromHardware(); // 只能在类内部触发事件 TemperatureChanged?.Invoke(temp); } } // 客户端代码 var safeSensor new TemperatureSensor_Safe(); safeSensor.TemperatureChanged (temp) Console.WriteLine($温度: {temp}℃); // safeSensor.TemperatureChanged null; // 编译错误不能直接赋值 // safeSensor.TemperatureChanged?.Invoke(100); // 编译错误不能在类外部触发事件 var unsafeSensor new TemperatureSensor_Unsafe(); unsafeSensor.OnTemperatureChanged null; // 允许危险操作 unsafeSensor.OnTemperatureChanged?.Invoke(100); // 允许危险操作看到区别了吗事件为委托加了一把锁把“调用”和“赋值”的权力牢牢锁在了类的内部只对外暴露“订阅”和“退订”的接口。这是事件最核心、最本质的价值它确保了发布者对自己通知机制的完全控制权是构建健壮、松耦合事件驱动系统的基石。2. 事件声明的“标准姿势”EventHandler 与自定义 EventArgs理解了为什么需要事件之后我们来看看在C#中如何规范地声明和使用它。虽然你可以像上面例子一样用event ActionT这种简单方式但在实际的企业级开发或框架设计中有一套更标准、更强大的模式。这套模式的核心是两个伙伴EventHandler委托和EventArgs类。2.1 标准事件模式剖析1.EventArgs基类这是所有事件参数的“老祖宗”一个简单的类主要用来在事件触发时从发布者向订阅者传递数据。微软预定义了一个泛型版本EventArgsT但更常见的做法是为你的事件自定义一个派生类。// 自定义事件参数类用于传递温度数据 public class TemperatureChangedEventArgs : EventArgs { public float OldTemperature { get; } public float NewTemperature { get; } public DateTime ChangeTime { get; } public TemperatureChangedEventArgs(float oldTemp, float newTemp) { OldTemperature oldTemp; NewTemperature newTemp; ChangeTime DateTime.Now; } }为什么要自定义EventArgs因为它让事件传递的数据具有强类型和自描述性。比起直接传递一个float传递一个TemperatureChangedEventArgs对象能包含更丰富的上下文信息如旧温度、变化时间而且后续扩展新字段也不会破坏现有订阅者的签名。2.EventHandlerTEventArgs委托这是.NET框架中用于事件的标准委托类型。它的签名是public delegate void EventHandlerTEventArgs(object sender, TEventArgs e) where TEventArgs : EventArgs;object sender: 触发事件的对象本身。订阅者通过这个参数知道是“谁”发出了通知。这在有多个相同类型事件源时非常有用。TEventArgs e: 事件参数包含了本次事件相关的所有数据。3. 完整的事件声明与使用流程结合以上两点我们重写温度传感器的例子// 1. 定义事件参数 public class TemperatureChangedEventArgs : EventArgs { public float NewTemperature { get; } public TemperatureChangedEventArgs(float newTemp) NewTemperature newTemp; } // 2. 发布者类 public class StandardTemperatureSensor { private float _currentTemperature; // 3. 使用标准模式声明事件 public event EventHandlerTemperatureChangedEventArgs TemperatureChanged; // 4. 定义触发事件的辅助方法约定俗称叫 OnXXX protected virtual void OnTemperatureChanged(TemperatureChangedEventArgs e) { // 空值条件运算符 ?. 是线程安全的调用方式 TemperatureChanged?.Invoke(this, e); } public void SimulateTemperatureChange(float newTemp) { if (Math.Abs(newTemp - _currentTemperature) 0.1) // 温度变化超过0.1度才触发 { var oldTemp _currentTemperature; _currentTemperature newTemp; // 5. 在合适的业务逻辑点触发事件 OnTemperatureChanged(new TemperatureChangedEventArgs(newTemp)); } } } // 6. 订阅者类 public class TemperatureDisplay { public void Subscribe(StandardTemperatureSensor sensor) { sensor.TemperatureChanged Sensor_TemperatureChanged; } // 7. 事件处理方法签名必须与委托匹配 private void Sensor_TemperatureChanged(object sender, TemperatureChangedEventArgs e) { // sender 就是 sensor 对象本身可以强制转换后使用 var theSensor sender as StandardTemperatureSensor; Console.WriteLine($[显示面板] 温度更新: {e.NewTemperature:F1}℃); } }提示OnTemperatureChanged方法被设计为protected virtual是一个良好实践。protected允许派生类重写触发事件的逻辑比如添加日志virtual则为重写提供了可能。即使你不打算派生养成这个习惯也能让代码更符合框架设计规范。2.2 为什么坚持标准模式你可能会觉得这套模式比简单的event Actionfloat繁琐得多。但在实际项目中尤其是编写会被他人复用的组件库时它有不可替代的优势一致性.NET 整个基础库如 WinForms, WPF, ASP.NET的事件都遵循此模式。使用它能让你的代码与生态系统无缝融合其他开发者一看就懂。扩展性EventArgs对象可以随时添加新的属性而不会破坏现有的事件委托签名因为传递的都是同一个对象。如果直接用Actionfloat, DateTime增加参数就意味着所有订阅者的方法签名都要改。信息丰富sender参数让订阅者能直接拿到事件源无需通过其他全局变量或复杂作用域来查找。工具支持Visual Studio 等IDE对标准模式有很好的支持比如输入后按Tab键可以自动生成符合签名的事件处理方法。一个常见的简化非泛型 EventHandler对于不需要传递额外数据的事件可以使用非泛型的EventHandler委托它等价于EventHandlerEventArgs。这时EventArgs.Empty是一个静态的空实例用于表示没有额外数据。public class Connection { public event EventHandler Connected; // 等价于 EventHandlerEventArgs public void Connect() { // ... 连接逻辑 OnConnected(); } protected virtual void OnConnected() { Connected?.Invoke(this, EventArgs.Empty); } }3. 事件使用的实战细节与高级技巧掌握了标准模式我们来看看在真实项目中使用事件时有哪些必须注意的细节和可以提升效率的高级技巧。这些知识很少在入门教程里提到但却是写出稳健事件驱动代码的关键。3.1 事件订阅与内存泄漏一个隐蔽的“坑”这是使用事件时最容易出错也最危险的地方。事件订阅会形成从发布者到订阅者的一个强引用。如果订阅者是一个对象并且没有正确取消订阅那么即使你在代码中已经不再使用这个订阅者对象垃圾回收器GC也无法回收它因为发布者还“拽着”它不放。public class Publisher { public event EventHandler SomethingHappened; } public class Subscriber { public string Name { get; set; } public Subscriber(Publisher pub) { // 订阅事件 pub.SomethingHappened HandleEvent; } private void HandleEvent(object sender, EventArgs e) { Console.WriteLine(${Name} 收到了事件.); } } // 测试代码 var publisher new Publisher(); var subscriber new Subscriber(publisher) { Name 订阅者A }; subscriber null; // 我们认为订阅者A可以被回收了 GC.Collect(); // 强制垃圾回收 GC.WaitForPendingFinalizers(); // 但此时publisher.SomethingHappened 委托链里仍然挂着对 subscriber.HandleEvent 方法的引用 // 订阅者A对象实际上并没有被释放造成了内存泄漏。如何避免及时取消订阅 (-)当订阅者生命周期结束时务必取消订阅。public class Subscriber : IDisposable { private Publisher _publisher; public Subscriber(Publisher pub) { _publisher pub; _publisher.SomethingHappened HandleEvent; } public void Dispose() { // 在Dispose或析构函数中取消订阅 if (_publisher ! null) { _publisher.SomethingHappened - HandleEvent; _publisher null; } } }使用弱事件模式对于某些框架如WPF存在WeakEventManager或社区库如WeakEventHandler它们使用弱引用允许订阅者在被发布者引用的情况下仍能被GC回收。但这会带来一定的性能开销和复杂度一般只在特定场景使用。让发布者生命周期更短如果发布者对象本身生命周期很短那么订阅者自然会被释放。这在一些临时性的UI控件或页面中很常见。3.2 在多线程环境下安全地触发事件事件触发Invoke本质上是一个多播委托的调用它不是线程安全的。考虑这样一个场景线程A正在遍历委托调用列表执行订阅者的方法此时线程B恰好执行了-操作来取消订阅。这可能会导致遍历过程中集合被修改从而引发InvalidOperationException。更安全的做法是在触发事件前获取委托的一个本地副本public class ThreadSafePublisher { public event EventHandlerEventArgs SomethingHappened; protected virtual void OnSomethingHappened() { // 关键步骤获取委托的本地副本 EventHandlerEventArgs handler SomethingHappened; if (handler ! null) { handler(this, EventArgs.Empty); } } }在C# 6.0及以后使用空值条件运算符?.是线程安全的因为它在计算Invoke的左值时会创建一个临时副本。所以SomethingHappened?.Invoke(this, args);这种写法本身就是线程安全的可以放心使用。但如果你需要更复杂的同步控制比如确保一系列操作在事件触发前后是原子的则可能需要使用lock语句。private readonly object _eventLock new object(); public event EventHandlerEventArgs SomethingHappened; protected virtual void OnSomethingHappened() { EventHandlerEventArgs localHandler; lock (_eventLock) // 锁定对委托实例的访问 { localHandler SomethingHappened; } localHandler?.Invoke(this, EventArgs.Empty); }3.3 自定义事件访问器add/remove绝大多数情况下我们使用public event EventHandler Xxx;这种简写形式。编译器会自动为我们生成一个私有的委托字段以及add和remove访问器。但有时候我们需要对事件的订阅和退订过程进行更精细的控制比如记录日志、进行权限校验、或者将事件存储到自定义的集合中。这时就可以使用完整的事件属性语法。public class LoggingPublisher { // 1. 声明一个私有的委托字段作为后备存储 private EventHandlerEventArgs _somethingHappened; // 2. 使用完整的事件声明 public event EventHandlerEventArgs SomethingHappened { add { Console.WriteLine($订阅者 {value?.Method.Name} 正在订阅。); // 这里可以加入线程同步锁 lock(_eventLock) _somethingHappened value; } remove { Console.WriteLine($订阅者 {value?.Method.Name} 正在退订。); // 这里可以加入线程同步锁 lock(_eventLock) _somethingHappened - value; } } protected virtual void OnSomethingHappened() { _somethingHappened?.Invoke(this, EventArgs.Empty); } }这种用法相对少见通常用于框架开发或需要高度定制事件存储逻辑的场景。对于日常业务开发简写形式完全够用。3.4 使用泛型与Lambda表达式简化事件处理在现代C#中结合泛型和Lambda表达式可以让事件处理代码更简洁。例如为一个简单的属性变更通知创建通用事件public class ObservableObjectT { private T _value; public event EventHandlerT ValueChanged; public T Value { get _value; set { if (!EqualityComparerT.Default.Equals(_value, value)) { _value value; ValueChanged?.Invoke(this, _value); } } } } // 使用 var obj new ObservableObjectint(); obj.ValueChanged (sender, newValue) Console.WriteLine($值变为: {newValue}); obj.Value 10; // 输出值变为: 10 obj.Value 20; // 输出值变为: 20但要注意Lambda表达式创建的是匿名方法如果你需要取消订阅必须将Lambda表达式赋值给一个委托变量然后用这个变量进行-操作。EventHandlerint handler (s, v) Console.WriteLine(v); obj.ValueChanged handler; // ... 后续操作 obj.ValueChanged - handler; // 正确取消订阅 // obj.ValueChanged - (s, v) Console.WriteLine(v); // 错误这无法取消订阅因为生成了新的委托实例4. 真实场景剖析从WinForms按钮点击到自定义异步事件理论说再多不如看实战。我们通过两个典型的应用场景来串联和理解事件机制是如何工作的。4.1 场景一WinForms/WPF中的事件处理Windows桌面开发是事件驱动编程最经典的领域。当你拖拽一个按钮到窗体上双击它IDE会自动生成如下代码// WinForms 示例 public partial class MainForm : Form { public MainForm() { InitializeComponent(); // 编译器/设计器生成的订阅代码 this.button1.Click new System.EventHandler(this.button1_Click); } // 事件处理方法 private void button1_Click(object sender, EventArgs e) { MessageBox.Show(按钮被点击了); } }这里的Click事件就是标准的EventHandler类型。sender是那个被点击的button1对象e是EventArgs.Empty因为按钮点击不需要额外参数。整个GUI应用的主循环就是一个巨大的事件监听器等待着用户输入鼠标、键盘或系统消息然后触发相应控件的事件。深入一步事件冒泡与路由事件在WPF中事件系统更复杂引入了“路由事件”的概念。一个事件比如鼠标点击可以从源元素如一个TextBlock向上冒泡或向下隧道穿过视觉树被路径上的多个父元素或子元素处理。这类似于Web开发中的“事件冒泡”。WPF通过RoutedEventArgs及其Handled属性来控制事件的传播。如果你在处理程序中设置e.Handled true;那么这个事件就不会再继续向上传递了。这为实现复杂UI交互如自定义控件、拖放提供了极大的灵活性。4.2 场景二实现一个带异步通知的文件系统监视器假设我们要写一个工具监视某个目录下的文件变化创建、修改、删除并在变化发生时异步通知多个订阅者同时要保证通知顺序和错误不互相影响。using System.IO; public class AsyncFileWatcher : IDisposable { private readonly FileSystemWatcher _watcher; private readonly string _path; // 定义自定义事件参数 public class FileChangedEventArgs : EventArgs { public string FullPath { get; } public WatcherChangeTypes ChangeType { get; } public FileChangedEventArgs(string path, WatcherChangeTypes type) { FullPath path; ChangeType type; } } // 声明异步事件。注意使用 EventHandlerT 的异步版本并不直接存在这是一种常见模式。 public event EventHandlerFileChangedEventArgs FileChanged; public AsyncFileWatcher(string directoryPath) { _path directoryPath; _watcher new FileSystemWatcher(_path); _watcher.NotifyFilter NotifyFilters.FileName | NotifyFilters.LastWrite; _watcher.EnableRaisingEvents true; // 订阅底层 FileSystemWatcher 的事件 _watcher.Created OnFileSystemEvent; _watcher.Changed OnFileSystemEvent; _watcher.Deleted OnFileSystemEvent; _watcher.Renamed OnFileSystemEvent; } private async void OnFileSystemEvent(object sender, FileSystemEventArgs e) { // 注意这里是 async void通常只用于事件处理程序。 // 立即触发我们自定义的同步事件通知那些需要快速响应的订阅者如果有的话。 // 但更常见的做法是异步触发。 // 异步触发事件获取委托列表然后异步调用每个处理程序 var handlers FileChanged; if (handlers ! null) { var args new FileChangedEventArgs(e.FullPath, e.ChangeType); // 由于 EventHandler 不是返回 Task 的委托我们需要手动处理异步。 // 更好的模式是定义自己的异步事件委托例如 Funcobject, TEventArgs, Task。 // 这里我们简单地将同步调用包装在 Task.Run 中并忽略错误生产环境需要处理。 foreach (EventHandlerFileChangedEventArgs handler in handlers.GetInvocationList()) { try { // 使用 Task.Run 将同步处理程序调用放到线程池避免阻塞文件系统监视线程。 // 如果处理程序本身是异步的这种模式就不合适了。 await Task.Run(() handler(this, args)).ConfigureAwait(false); } catch (Exception ex) { // 记录日志但不要影响其他订阅者 Console.WriteLine($事件处理程序出错: {ex.Message}); } } } } public void Dispose() { _watcher?.Dispose(); } } // 使用示例 public class Program { public static async Task Main() { using var watcher new AsyncFileWatcher(C:\MyWatchFolder); watcher.FileChanged LogToConsole; watcher.FileChanged UpdateDatabaseAsync; // 假设这是一个异步方法 Console.WriteLine(开始监视按任意键退出...); Console.ReadKey(); // Dispose 时会自动取消事件订阅 } private static void LogToConsole(object sender, AsyncFileWatcher.FileChangedEventArgs e) { Console.WriteLine($[{DateTime.Now:HH:mm:ss}] 文件 {e.FullPath} 被 {e.ChangeType}); } private static async Task UpdateDatabaseAsync(object sender, AsyncFileWatcher.FileChangedEventArgs e) { // 模拟一个耗时的数据库操作 await Task.Delay(100); Console.WriteLine($[数据库] 已记录文件变更: {Path.GetFileName(e.FullPath)}); } }这个例子揭示了几个高级主题异步事件处理标准的EventHandler不是异步的。处理耗时操作时要么在处理方法内使用async void需谨慎处理异常要么定义自己的异步事件委托类型如Funcobject, TEventArgs, Task要么像例子中一样在触发端使用Task.Run包装。错误隔离在遍历GetInvocationList()调用每个订阅者时用try-catch包裹每个调用确保一个订阅者的崩溃不会影响其他订阅者。资源管理AsyncFileWatcher实现了IDisposable在Dispose时清理底层的FileSystemWatcher这会自动解除其内部的事件订阅是避免内存泄漏的关键。4.3 场景三基于事件的简单状态机事件非常适合用来实现轻量级的、响应式的状态机。例如一个下载器的状态管理public class Downloader { public enum DownloadState { Idle, Downloading, Paused, Completed, Failed } private DownloadState _currentState DownloadState.Idle; public event EventHandlerDownloadState StateChanged; public event EventHandlerdouble ProgressChanged; // 进度事件 public DownloadState CurrentState { get _currentState; private set { if (_currentState ! value) { _currentState value; StateChanged?.Invoke(this, _currentState); } } } public async Task DownloadAsync(string url) { if (CurrentState ! DownloadState.Idle CurrentState ! DownloadState.Paused) throw new InvalidOperationException(下载器不处于可开始状态。); CurrentState DownloadState.Downloading; try { // 模拟下载 for (int i 0; i 100; i 10) { if (CurrentState DownloadState.Paused) { // 等待恢复信号这里简化处理 await Task.Delay(1000); if (CurrentState DownloadState.Paused) CurrentState DownloadState.Downloading; } await Task.Delay(500); // 模拟网络延迟 ProgressChanged?.Invoke(this, i); } CurrentState DownloadState.Completed; } catch (Exception) { CurrentState DownloadState.Failed; throw; } } public void Pause() CurrentState DownloadState.Paused; public void Resume() CurrentState DownloadState.Downloading; // 简化逻辑 }在这个例子中StateChanged事件将下载器内部状态的每一次转变都广播出去。UI层可以订阅这个事件实时更新按钮如“开始”变为“暂停”、“继续”、进度条和状态文本。这种模式将核心逻辑下载与界面更新UI彻底解耦使得两者可以独立开发和测试。5. 事件与委托的抉择何时用事件何时用委托学到这里你可能又会有疑问既然事件本质上是委托那我什么时候该用公共委托字段什么时候该用事件呢这里有一个非常清晰的决策边界使用公共委托字段的场景罕见你需要完全的控制权你明确地希望类的调用者不仅能订阅/退订还能直接替换整个回调列表使用或直接触发回调。这通常出现在一些高度灵活、需要“接管”行为的框架底层代码中。委托作为回调参数最常见的是将委托作为方法参数传递比如ListT.ForEach(ActionT action)或者Task的构造函数。这时你是在“消费”一个委托而不是“发布”一个事件。简单的单播回调如果确定一个对象只需要一个回调方法并且生命周期由你严格控制使用公共委托字段更简单。例如System.Threading.Timer的构造函数接受一个TimerCallback委托。使用事件的场景绝大多数情况你正在设计一个类需要向外部提供通知机制这是事件最核心的用途。你的类内部状态发生变化如属性改变、操作完成、错误发生你需要通知其他对象但又不想暴露内部的控制权。遵循“封装”原则默认选择事件。遵循.NET框架设计规范如果你在编写一个组件、控件或任何可能被他人复用的库请务必使用标准的事件模式以保证与整个.NET生态的一致性。需要多播多个订阅者事件天然支持多播委托可以方便地让多个对象监听同一个通知。一个简单的经验法则当你需要实现“观察者模式”Publisher-Subscriber时就用事件。当你只是需要传递一个“方法”作为参数时就用委托。最后再分享一个我个人在代码审查中常看到的问题滥用事件。有些开发者会把事件用在原本应该用简单方法调用的地方。比如一个类A只被另一个类B使用并且B严格掌控着A的生命周期它们之间是紧密的“组合”关系。这时A状态变化直接调用B的一个公共方法可能更简单、更高效而不是通过事件来绕一圈。事件引入了间接性适用于解耦未知的、多个的订阅者。如果关系是已知的、一对一的直接依赖注入或接口调用往往更清晰。 C#事件机制深度解析：从委托封装到安全事件驱动编程
1. 从“委托”到“事件”为什么我们需要这个“包装器”如果你已经跟着上一篇内容把C#委托的来龙去脉搞清楚了那你可能会有一个疑问委托本身已经能很好地实现方法的间接调用和回调了为什么还要多出一个“事件”的概念这不是把简单问题复杂化了吗我刚开始学的时候也是这么想的总觉得事件就是委托的一个“马甲”直到在实际项目中踩了几个大坑才彻底明白微软设计“事件”这个语法糖的良苦用心。简单来说事件是对委托的一种封装和约束它的核心目标是解决一个在面向对象编程中至关重要的问题封装与安全。想象一个场景你写了一个温度传感器类TemperatureSensor它内部有一个委托字段OnTemperatureChanged用来通知外部温度发生了变化。如果这个字段是public的那么任何使用你这个类的代码都可以直接对这个委托做三件“危险”的事情直接赋值 ()后来的订阅者会直接把先前的订阅者全部覆盖掉。随意调用外部代码可以随时、随地、以任何参数触发这个“通知”完全绕过了TemperatureSensor类内部的逻辑控制。清空所有订阅 ( null)这会导致所有监听者都收不到通知系统行为变得不可预测。这就像你把家里大门的钥匙复制了好几份随便发给邻居和朋友。他们不仅可以进来订阅还可以换掉你的锁赋值甚至在你不在家的时候以你的名义开派对随意触发。这显然违背了类的“封装”原则——类的内部状态和通知机制应该由类自己来管理。事件Event就是为了解决这个问题而生的。你可以把事件理解为一个对委托进行了访问限制的“属性”。对于事件的发布者比如TemperatureSensor来说它在类内部看到的还是一个完整的委托可以自由地添加/移除响应方法并在合适的时机触发它。但对于类的外部订阅者来说他们只能看到两个操作订阅和-取消订阅。他们既不能直接赋值也不能直接触发这个事件。用代码来对比一下就很清晰了// 使用公共委托字段 - 不安全 public class TemperatureSensor_Unsafe { public Actionfloat OnTemperatureChanged; // 公共委托字段 public void ReadSensor() { float temp ReadFromHardware(); // 外部代码可以直接sensor.OnTemperatureChanged null; 或者 sensor.OnTemperatureChanged?.Invoke(999); OnTemperatureChanged?.Invoke(temp); } } // 使用事件 - 安全 public class TemperatureSensor_Safe { // 声明一个事件。这里底层仍然是一个委托但对外的接口被限制了。 public event Actionfloat TemperatureChanged; public void ReadSensor() { float temp ReadFromHardware(); // 只能在类内部触发事件 TemperatureChanged?.Invoke(temp); } } // 客户端代码 var safeSensor new TemperatureSensor_Safe(); safeSensor.TemperatureChanged (temp) Console.WriteLine($温度: {temp}℃); // safeSensor.TemperatureChanged null; // 编译错误不能直接赋值 // safeSensor.TemperatureChanged?.Invoke(100); // 编译错误不能在类外部触发事件 var unsafeSensor new TemperatureSensor_Unsafe(); unsafeSensor.OnTemperatureChanged null; // 允许危险操作 unsafeSensor.OnTemperatureChanged?.Invoke(100); // 允许危险操作看到区别了吗事件为委托加了一把锁把“调用”和“赋值”的权力牢牢锁在了类的内部只对外暴露“订阅”和“退订”的接口。这是事件最核心、最本质的价值它确保了发布者对自己通知机制的完全控制权是构建健壮、松耦合事件驱动系统的基石。2. 事件声明的“标准姿势”EventHandler 与自定义 EventArgs理解了为什么需要事件之后我们来看看在C#中如何规范地声明和使用它。虽然你可以像上面例子一样用event ActionT这种简单方式但在实际的企业级开发或框架设计中有一套更标准、更强大的模式。这套模式的核心是两个伙伴EventHandler委托和EventArgs类。2.1 标准事件模式剖析1.EventArgs基类这是所有事件参数的“老祖宗”一个简单的类主要用来在事件触发时从发布者向订阅者传递数据。微软预定义了一个泛型版本EventArgsT但更常见的做法是为你的事件自定义一个派生类。// 自定义事件参数类用于传递温度数据 public class TemperatureChangedEventArgs : EventArgs { public float OldTemperature { get; } public float NewTemperature { get; } public DateTime ChangeTime { get; } public TemperatureChangedEventArgs(float oldTemp, float newTemp) { OldTemperature oldTemp; NewTemperature newTemp; ChangeTime DateTime.Now; } }为什么要自定义EventArgs因为它让事件传递的数据具有强类型和自描述性。比起直接传递一个float传递一个TemperatureChangedEventArgs对象能包含更丰富的上下文信息如旧温度、变化时间而且后续扩展新字段也不会破坏现有订阅者的签名。2.EventHandlerTEventArgs委托这是.NET框架中用于事件的标准委托类型。它的签名是public delegate void EventHandlerTEventArgs(object sender, TEventArgs e) where TEventArgs : EventArgs;object sender: 触发事件的对象本身。订阅者通过这个参数知道是“谁”发出了通知。这在有多个相同类型事件源时非常有用。TEventArgs e: 事件参数包含了本次事件相关的所有数据。3. 完整的事件声明与使用流程结合以上两点我们重写温度传感器的例子// 1. 定义事件参数 public class TemperatureChangedEventArgs : EventArgs { public float NewTemperature { get; } public TemperatureChangedEventArgs(float newTemp) NewTemperature newTemp; } // 2. 发布者类 public class StandardTemperatureSensor { private float _currentTemperature; // 3. 使用标准模式声明事件 public event EventHandlerTemperatureChangedEventArgs TemperatureChanged; // 4. 定义触发事件的辅助方法约定俗称叫 OnXXX protected virtual void OnTemperatureChanged(TemperatureChangedEventArgs e) { // 空值条件运算符 ?. 是线程安全的调用方式 TemperatureChanged?.Invoke(this, e); } public void SimulateTemperatureChange(float newTemp) { if (Math.Abs(newTemp - _currentTemperature) 0.1) // 温度变化超过0.1度才触发 { var oldTemp _currentTemperature; _currentTemperature newTemp; // 5. 在合适的业务逻辑点触发事件 OnTemperatureChanged(new TemperatureChangedEventArgs(newTemp)); } } } // 6. 订阅者类 public class TemperatureDisplay { public void Subscribe(StandardTemperatureSensor sensor) { sensor.TemperatureChanged Sensor_TemperatureChanged; } // 7. 事件处理方法签名必须与委托匹配 private void Sensor_TemperatureChanged(object sender, TemperatureChangedEventArgs e) { // sender 就是 sensor 对象本身可以强制转换后使用 var theSensor sender as StandardTemperatureSensor; Console.WriteLine($[显示面板] 温度更新: {e.NewTemperature:F1}℃); } }提示OnTemperatureChanged方法被设计为protected virtual是一个良好实践。protected允许派生类重写触发事件的逻辑比如添加日志virtual则为重写提供了可能。即使你不打算派生养成这个习惯也能让代码更符合框架设计规范。2.2 为什么坚持标准模式你可能会觉得这套模式比简单的event Actionfloat繁琐得多。但在实际项目中尤其是编写会被他人复用的组件库时它有不可替代的优势一致性.NET 整个基础库如 WinForms, WPF, ASP.NET的事件都遵循此模式。使用它能让你的代码与生态系统无缝融合其他开发者一看就懂。扩展性EventArgs对象可以随时添加新的属性而不会破坏现有的事件委托签名因为传递的都是同一个对象。如果直接用Actionfloat, DateTime增加参数就意味着所有订阅者的方法签名都要改。信息丰富sender参数让订阅者能直接拿到事件源无需通过其他全局变量或复杂作用域来查找。工具支持Visual Studio 等IDE对标准模式有很好的支持比如输入后按Tab键可以自动生成符合签名的事件处理方法。一个常见的简化非泛型 EventHandler对于不需要传递额外数据的事件可以使用非泛型的EventHandler委托它等价于EventHandlerEventArgs。这时EventArgs.Empty是一个静态的空实例用于表示没有额外数据。public class Connection { public event EventHandler Connected; // 等价于 EventHandlerEventArgs public void Connect() { // ... 连接逻辑 OnConnected(); } protected virtual void OnConnected() { Connected?.Invoke(this, EventArgs.Empty); } }3. 事件使用的实战细节与高级技巧掌握了标准模式我们来看看在真实项目中使用事件时有哪些必须注意的细节和可以提升效率的高级技巧。这些知识很少在入门教程里提到但却是写出稳健事件驱动代码的关键。3.1 事件订阅与内存泄漏一个隐蔽的“坑”这是使用事件时最容易出错也最危险的地方。事件订阅会形成从发布者到订阅者的一个强引用。如果订阅者是一个对象并且没有正确取消订阅那么即使你在代码中已经不再使用这个订阅者对象垃圾回收器GC也无法回收它因为发布者还“拽着”它不放。public class Publisher { public event EventHandler SomethingHappened; } public class Subscriber { public string Name { get; set; } public Subscriber(Publisher pub) { // 订阅事件 pub.SomethingHappened HandleEvent; } private void HandleEvent(object sender, EventArgs e) { Console.WriteLine(${Name} 收到了事件.); } } // 测试代码 var publisher new Publisher(); var subscriber new Subscriber(publisher) { Name 订阅者A }; subscriber null; // 我们认为订阅者A可以被回收了 GC.Collect(); // 强制垃圾回收 GC.WaitForPendingFinalizers(); // 但此时publisher.SomethingHappened 委托链里仍然挂着对 subscriber.HandleEvent 方法的引用 // 订阅者A对象实际上并没有被释放造成了内存泄漏。如何避免及时取消订阅 (-)当订阅者生命周期结束时务必取消订阅。public class Subscriber : IDisposable { private Publisher _publisher; public Subscriber(Publisher pub) { _publisher pub; _publisher.SomethingHappened HandleEvent; } public void Dispose() { // 在Dispose或析构函数中取消订阅 if (_publisher ! null) { _publisher.SomethingHappened - HandleEvent; _publisher null; } } }使用弱事件模式对于某些框架如WPF存在WeakEventManager或社区库如WeakEventHandler它们使用弱引用允许订阅者在被发布者引用的情况下仍能被GC回收。但这会带来一定的性能开销和复杂度一般只在特定场景使用。让发布者生命周期更短如果发布者对象本身生命周期很短那么订阅者自然会被释放。这在一些临时性的UI控件或页面中很常见。3.2 在多线程环境下安全地触发事件事件触发Invoke本质上是一个多播委托的调用它不是线程安全的。考虑这样一个场景线程A正在遍历委托调用列表执行订阅者的方法此时线程B恰好执行了-操作来取消订阅。这可能会导致遍历过程中集合被修改从而引发InvalidOperationException。更安全的做法是在触发事件前获取委托的一个本地副本public class ThreadSafePublisher { public event EventHandlerEventArgs SomethingHappened; protected virtual void OnSomethingHappened() { // 关键步骤获取委托的本地副本 EventHandlerEventArgs handler SomethingHappened; if (handler ! null) { handler(this, EventArgs.Empty); } } }在C# 6.0及以后使用空值条件运算符?.是线程安全的因为它在计算Invoke的左值时会创建一个临时副本。所以SomethingHappened?.Invoke(this, args);这种写法本身就是线程安全的可以放心使用。但如果你需要更复杂的同步控制比如确保一系列操作在事件触发前后是原子的则可能需要使用lock语句。private readonly object _eventLock new object(); public event EventHandlerEventArgs SomethingHappened; protected virtual void OnSomethingHappened() { EventHandlerEventArgs localHandler; lock (_eventLock) // 锁定对委托实例的访问 { localHandler SomethingHappened; } localHandler?.Invoke(this, EventArgs.Empty); }3.3 自定义事件访问器add/remove绝大多数情况下我们使用public event EventHandler Xxx;这种简写形式。编译器会自动为我们生成一个私有的委托字段以及add和remove访问器。但有时候我们需要对事件的订阅和退订过程进行更精细的控制比如记录日志、进行权限校验、或者将事件存储到自定义的集合中。这时就可以使用完整的事件属性语法。public class LoggingPublisher { // 1. 声明一个私有的委托字段作为后备存储 private EventHandlerEventArgs _somethingHappened; // 2. 使用完整的事件声明 public event EventHandlerEventArgs SomethingHappened { add { Console.WriteLine($订阅者 {value?.Method.Name} 正在订阅。); // 这里可以加入线程同步锁 lock(_eventLock) _somethingHappened value; } remove { Console.WriteLine($订阅者 {value?.Method.Name} 正在退订。); // 这里可以加入线程同步锁 lock(_eventLock) _somethingHappened - value; } } protected virtual void OnSomethingHappened() { _somethingHappened?.Invoke(this, EventArgs.Empty); } }这种用法相对少见通常用于框架开发或需要高度定制事件存储逻辑的场景。对于日常业务开发简写形式完全够用。3.4 使用泛型与Lambda表达式简化事件处理在现代C#中结合泛型和Lambda表达式可以让事件处理代码更简洁。例如为一个简单的属性变更通知创建通用事件public class ObservableObjectT { private T _value; public event EventHandlerT ValueChanged; public T Value { get _value; set { if (!EqualityComparerT.Default.Equals(_value, value)) { _value value; ValueChanged?.Invoke(this, _value); } } } } // 使用 var obj new ObservableObjectint(); obj.ValueChanged (sender, newValue) Console.WriteLine($值变为: {newValue}); obj.Value 10; // 输出值变为: 10 obj.Value 20; // 输出值变为: 20但要注意Lambda表达式创建的是匿名方法如果你需要取消订阅必须将Lambda表达式赋值给一个委托变量然后用这个变量进行-操作。EventHandlerint handler (s, v) Console.WriteLine(v); obj.ValueChanged handler; // ... 后续操作 obj.ValueChanged - handler; // 正确取消订阅 // obj.ValueChanged - (s, v) Console.WriteLine(v); // 错误这无法取消订阅因为生成了新的委托实例4. 真实场景剖析从WinForms按钮点击到自定义异步事件理论说再多不如看实战。我们通过两个典型的应用场景来串联和理解事件机制是如何工作的。4.1 场景一WinForms/WPF中的事件处理Windows桌面开发是事件驱动编程最经典的领域。当你拖拽一个按钮到窗体上双击它IDE会自动生成如下代码// WinForms 示例 public partial class MainForm : Form { public MainForm() { InitializeComponent(); // 编译器/设计器生成的订阅代码 this.button1.Click new System.EventHandler(this.button1_Click); } // 事件处理方法 private void button1_Click(object sender, EventArgs e) { MessageBox.Show(按钮被点击了); } }这里的Click事件就是标准的EventHandler类型。sender是那个被点击的button1对象e是EventArgs.Empty因为按钮点击不需要额外参数。整个GUI应用的主循环就是一个巨大的事件监听器等待着用户输入鼠标、键盘或系统消息然后触发相应控件的事件。深入一步事件冒泡与路由事件在WPF中事件系统更复杂引入了“路由事件”的概念。一个事件比如鼠标点击可以从源元素如一个TextBlock向上冒泡或向下隧道穿过视觉树被路径上的多个父元素或子元素处理。这类似于Web开发中的“事件冒泡”。WPF通过RoutedEventArgs及其Handled属性来控制事件的传播。如果你在处理程序中设置e.Handled true;那么这个事件就不会再继续向上传递了。这为实现复杂UI交互如自定义控件、拖放提供了极大的灵活性。4.2 场景二实现一个带异步通知的文件系统监视器假设我们要写一个工具监视某个目录下的文件变化创建、修改、删除并在变化发生时异步通知多个订阅者同时要保证通知顺序和错误不互相影响。using System.IO; public class AsyncFileWatcher : IDisposable { private readonly FileSystemWatcher _watcher; private readonly string _path; // 定义自定义事件参数 public class FileChangedEventArgs : EventArgs { public string FullPath { get; } public WatcherChangeTypes ChangeType { get; } public FileChangedEventArgs(string path, WatcherChangeTypes type) { FullPath path; ChangeType type; } } // 声明异步事件。注意使用 EventHandlerT 的异步版本并不直接存在这是一种常见模式。 public event EventHandlerFileChangedEventArgs FileChanged; public AsyncFileWatcher(string directoryPath) { _path directoryPath; _watcher new FileSystemWatcher(_path); _watcher.NotifyFilter NotifyFilters.FileName | NotifyFilters.LastWrite; _watcher.EnableRaisingEvents true; // 订阅底层 FileSystemWatcher 的事件 _watcher.Created OnFileSystemEvent; _watcher.Changed OnFileSystemEvent; _watcher.Deleted OnFileSystemEvent; _watcher.Renamed OnFileSystemEvent; } private async void OnFileSystemEvent(object sender, FileSystemEventArgs e) { // 注意这里是 async void通常只用于事件处理程序。 // 立即触发我们自定义的同步事件通知那些需要快速响应的订阅者如果有的话。 // 但更常见的做法是异步触发。 // 异步触发事件获取委托列表然后异步调用每个处理程序 var handlers FileChanged; if (handlers ! null) { var args new FileChangedEventArgs(e.FullPath, e.ChangeType); // 由于 EventHandler 不是返回 Task 的委托我们需要手动处理异步。 // 更好的模式是定义自己的异步事件委托例如 Funcobject, TEventArgs, Task。 // 这里我们简单地将同步调用包装在 Task.Run 中并忽略错误生产环境需要处理。 foreach (EventHandlerFileChangedEventArgs handler in handlers.GetInvocationList()) { try { // 使用 Task.Run 将同步处理程序调用放到线程池避免阻塞文件系统监视线程。 // 如果处理程序本身是异步的这种模式就不合适了。 await Task.Run(() handler(this, args)).ConfigureAwait(false); } catch (Exception ex) { // 记录日志但不要影响其他订阅者 Console.WriteLine($事件处理程序出错: {ex.Message}); } } } } public void Dispose() { _watcher?.Dispose(); } } // 使用示例 public class Program { public static async Task Main() { using var watcher new AsyncFileWatcher(C:\MyWatchFolder); watcher.FileChanged LogToConsole; watcher.FileChanged UpdateDatabaseAsync; // 假设这是一个异步方法 Console.WriteLine(开始监视按任意键退出...); Console.ReadKey(); // Dispose 时会自动取消事件订阅 } private static void LogToConsole(object sender, AsyncFileWatcher.FileChangedEventArgs e) { Console.WriteLine($[{DateTime.Now:HH:mm:ss}] 文件 {e.FullPath} 被 {e.ChangeType}); } private static async Task UpdateDatabaseAsync(object sender, AsyncFileWatcher.FileChangedEventArgs e) { // 模拟一个耗时的数据库操作 await Task.Delay(100); Console.WriteLine($[数据库] 已记录文件变更: {Path.GetFileName(e.FullPath)}); } }这个例子揭示了几个高级主题异步事件处理标准的EventHandler不是异步的。处理耗时操作时要么在处理方法内使用async void需谨慎处理异常要么定义自己的异步事件委托类型如Funcobject, TEventArgs, Task要么像例子中一样在触发端使用Task.Run包装。错误隔离在遍历GetInvocationList()调用每个订阅者时用try-catch包裹每个调用确保一个订阅者的崩溃不会影响其他订阅者。资源管理AsyncFileWatcher实现了IDisposable在Dispose时清理底层的FileSystemWatcher这会自动解除其内部的事件订阅是避免内存泄漏的关键。4.3 场景三基于事件的简单状态机事件非常适合用来实现轻量级的、响应式的状态机。例如一个下载器的状态管理public class Downloader { public enum DownloadState { Idle, Downloading, Paused, Completed, Failed } private DownloadState _currentState DownloadState.Idle; public event EventHandlerDownloadState StateChanged; public event EventHandlerdouble ProgressChanged; // 进度事件 public DownloadState CurrentState { get _currentState; private set { if (_currentState ! value) { _currentState value; StateChanged?.Invoke(this, _currentState); } } } public async Task DownloadAsync(string url) { if (CurrentState ! DownloadState.Idle CurrentState ! DownloadState.Paused) throw new InvalidOperationException(下载器不处于可开始状态。); CurrentState DownloadState.Downloading; try { // 模拟下载 for (int i 0; i 100; i 10) { if (CurrentState DownloadState.Paused) { // 等待恢复信号这里简化处理 await Task.Delay(1000); if (CurrentState DownloadState.Paused) CurrentState DownloadState.Downloading; } await Task.Delay(500); // 模拟网络延迟 ProgressChanged?.Invoke(this, i); } CurrentState DownloadState.Completed; } catch (Exception) { CurrentState DownloadState.Failed; throw; } } public void Pause() CurrentState DownloadState.Paused; public void Resume() CurrentState DownloadState.Downloading; // 简化逻辑 }在这个例子中StateChanged事件将下载器内部状态的每一次转变都广播出去。UI层可以订阅这个事件实时更新按钮如“开始”变为“暂停”、“继续”、进度条和状态文本。这种模式将核心逻辑下载与界面更新UI彻底解耦使得两者可以独立开发和测试。5. 事件与委托的抉择何时用事件何时用委托学到这里你可能又会有疑问既然事件本质上是委托那我什么时候该用公共委托字段什么时候该用事件呢这里有一个非常清晰的决策边界使用公共委托字段的场景罕见你需要完全的控制权你明确地希望类的调用者不仅能订阅/退订还能直接替换整个回调列表使用或直接触发回调。这通常出现在一些高度灵活、需要“接管”行为的框架底层代码中。委托作为回调参数最常见的是将委托作为方法参数传递比如ListT.ForEach(ActionT action)或者Task的构造函数。这时你是在“消费”一个委托而不是“发布”一个事件。简单的单播回调如果确定一个对象只需要一个回调方法并且生命周期由你严格控制使用公共委托字段更简单。例如System.Threading.Timer的构造函数接受一个TimerCallback委托。使用事件的场景绝大多数情况你正在设计一个类需要向外部提供通知机制这是事件最核心的用途。你的类内部状态发生变化如属性改变、操作完成、错误发生你需要通知其他对象但又不想暴露内部的控制权。遵循“封装”原则默认选择事件。遵循.NET框架设计规范如果你在编写一个组件、控件或任何可能被他人复用的库请务必使用标准的事件模式以保证与整个.NET生态的一致性。需要多播多个订阅者事件天然支持多播委托可以方便地让多个对象监听同一个通知。一个简单的经验法则当你需要实现“观察者模式”Publisher-Subscriber时就用事件。当你只是需要传递一个“方法”作为参数时就用委托。最后再分享一个我个人在代码审查中常看到的问题滥用事件。有些开发者会把事件用在原本应该用简单方法调用的地方。比如一个类A只被另一个类B使用并且B严格掌控着A的生命周期它们之间是紧密的“组合”关系。这时A状态变化直接调用B的一个公共方法可能更简单、更高效而不是通过事件来绕一圈。事件引入了间接性适用于解耦未知的、多个的订阅者。如果关系是已知的、一对一的直接依赖注入或接口调用往往更清晰。