事件是受保护的多播委托，编译器封装限制外部直接赋值、调用或读取；必须通过+=/-=订阅，且仅能在声明类内触发，标准做法是用?.Invoke()安全调用。
event 本质是受保护的多播委托
它不是语法糖，而是编译器对委托的一层封装：声明为 event 后，外部代码只能用 += 和 -= 订阅/取消订阅，不能直接赋值（=）、不能调用（Invoke()）、也不能读取其内部委托链。这保证了发布者对事件触发权的独占性。
- 如果你写
publisher.MyEvent = handler;→ 编译错误：无法对事件赋值 - 如果你写
publisher.MyEvent.Invoke();→ 编译错误：事件只能在声明它的类中触发 - 但
publisher.MyEvent += handler;✅ 合法；publisher.OnMyEvent();（内部方法）✅ 合法
触发事件必须走「空值检查 + Invoke」惯用写法
直接调用 MyEvent(...) 会抛 NullReferenceException，因为没人订阅时事件字段为 null。标准做法是封装一个受保护的 OnXXX 方法，并用空合并调用操作符 ?.Invoke()。
protected virtual void OnProcessCompleted(EventArgs e)
{
ProcessCompleted?.Invoke(this, e); // 安全触发，没人订阅也不崩
}- 别手写
if (ProcessCompleted != null) ProcessCompleted(...)—— 在多线程下仍有竞态风险 -
?.Invoke()是原子性的空检查 + 调用，.NET 6+ 更推荐此写法 - 参数中的
this是约定俗成的事件源（sender），方便订阅者反查发布者状态
订阅多个处理器时，执行顺序 = 订阅顺序，且全部同步执行
C# 事件默认是同步、按注册顺序逐个调用的。没有内置优先级、超时或异常隔离机制 —— 某个订阅者抛异常，后续订阅者将不会被调用。
- 订阅顺序决定执行顺序：
ev += A; ev += B;→ 总是先 A 后 B - 若
A中抛出未捕获异常，B不会执行（除非你在OnXXX里手动 try/catch 包裹每个调用） - 需要异步响应？得自己把处理逻辑扔进
Task.Run或用async void（⚠️不推荐）—— 但要注意：async void 无法被等待，异常会直接崩掉线程
用 EventHandler 传参比自定义委托更安全、更通用
比起手写 public delegate void DataReceivedHandler(string data);，优先用泛型 EventHandler。它自带 sender + e 结构，和 .NET 生态（WinForms/WPF/ASP.NET）完全兼容，也支持设计时智能提示。
public class TemperatureEventArgs : EventArgs
{
public double CurrentTemp { get; }
public TemperatureEventArgs(double temp) => CurrentTemp = temp;
}
// 发布者中
public event EventHandler TemperatureChanged;
protected virtual void OnTemperatureChanged(double temp)
=> TemperatureChanged?.Invoke(this, new TemperatureEventArgs(temp));
- 别用
Action<...>替代事件 —— 它没封装性，外部可随意调用/清空，破坏发布-订阅契约 - 如果真不需要 sender/e，也建议用
EventHandler（空参）而非裸委托，保持风格统一 - 自定义
EventArgs类应设为public sealed，避免被意外继承篡改语义
事件机制本身轻量，但滥用会导致内存泄漏（比如忘了 -=）、调试困难（调用栈深、谁注册了谁不知道）和同步阻塞。真正关键的不是“怎么写”，而是“谁该负责触发”“谁该负责清理订阅”——这些责任边界，比语法细节重要得多。
