C#怎么使用事件_C#定义事件和事件处理教程【攻略】

先给一个核心判断：C# 事件这玩意儿，与其说是“用”出来的，不如说是“设计出来再安全暴露”的。它本质上就是个带访问控制的委托，最大的价值就是防止外部代码随意调用或者清空你的处理逻辑。千万别一上来就写个event Action MyEvent，然后到处丢MyEvent?.Invoke()——这样搞，null检查、线程安全、内存泄漏这些坑，你迟早会踩个遍。

声明事件时，EventHandler 还是自定义委托？

首选 EventHandler 或 EventHandler，除非你真有那种“必须不带 object sender”的特殊需求。系统给的泛型版，天然能约束参数类型，省得你自己手写委托还容易写错。

• EventHandler：适合无参场景，或者你只想传个 EventArgs.Empty 意思一下，比如 public event EventHandler Loaded;
• EventHandler：需要传业务数据时用。注意，你的 MyEventArgs 必须继承 EventArgs，不然 WPF、WinForms、Blazor 这些框架根本认不出来
• 自己写 public delegate void DataReadyHandler(string data);？除非你在搞底层的通信协议适配，否则这就是在给维护加成本，完全可以省了。

触发事件，必须写 OnXXX 方法吗？

不强制，但强烈建议。直接在外部调用 MyEvent?.Invoke(...) 虽然也行，但那等于把封装性扔了，派生类想扩展或覆盖都没门。

• protected virtual void OnLoaded(EventArgs e) 是标准玩法。它既让子类能重写，又把那个烦人的null检查收口到一个地方
• 事件名叫 Loaded，对应方法就叫 OnLoaded，这是 .NET 约定俗成的事，别写什么 TriggerLoaded 或 FireLoaded，太奇怪了
• 调用前不用手动判空——MyEvent?.Invoke(this, e) 就够了，?. 已经替你处理了 null 的情况

订阅事件后，对象为什么不会被释放？

这是最常踩的坑。订阅者（比如窗体、ViewModel）拿着发布者（比如某个服务类）的引用，而发布者这边通过事件委托，反向也拿住了订阅者的引用。一来一回，循环引用就这么形成了，GC 根本认不出来，自然清不掉。

• 最直接的办法：显式取消订阅。写个 publisher.MyEvent -= handler;，尤其是在 IDisposable.Dispose() 或窗体的 OnClosed 里处理
• 弱事件模式（WeakEventManager）能用，但基本是 WPF 的特有场景；Blazor 里不如直接用组件的生命周期钩子 DisposeAsync
• 用 Lambda 订阅（publisher.MyEvent += (s, e) => { ... };）很方便，但问题是你没法取消了。除非先把这个 Lambda 赋给一个变量，再用变量去订阅

Blazor 里的 @onclick 和 C# 事件是一回事吗？

不是，两者本质上是两回事。Blazor 的 @onclick 是 DOM 事件绑定的语法，背后靠框架生成 Ja vaScript 互操作调用来实现，它触发的是组件里的 C# 方法，而不是传统意义上的 event 成员。你不能在 Blazor 组件里写个 public event EventHandler Clicked;，就指望 HTML 按钮自动触发它。

• 在 Blazor 里真正用得上 C# 事件的地方，是组件间的通信——比如父组件订阅子组件的 OnSubmit 事件，或者像 AuthenticationStateProvider.AuthenticationStateChanged 这种服务通知
• @onclick="HandleClick" 这里的 HandleClick，签名可以是 void HandleClick()，也可以是 void HandleClick(MouseEventArgs e)，框架会自动注入参数，你不用操心委托类型
• 如果真要跨组件发通知，推荐用 CascadingParameter 配合 EventCallback，比直接用裸事件更符合 Blazor 的设计哲学

说到底，事件机制本身不复杂，难的是在不同上下文里选对抽象层级。WinForms 里靠它驱动 UI，后台服务里靠它解耦模块，Blazor 里则要分清 DOM 绑定和 C# 通知的边界。别为了“用事件”而用。先想清楚：谁该知道这件事？什么时候知道？知道了之后，能不能被 GC 正常回收？想清楚了，再用。