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<t></t>
传参比自定义委托更安全、更通用
比起手写
public delegate void DataReceivedHandler(string data);，优先用泛型
EventHandler<customeventargs></customeventargs>。它自带 sender + e 结构，和 .NET 生态（WinForms/WPF/ASP.NET）完全兼容，也支持设计时智能提示。
public class TemperatureEventArgs : EventArgs
{
public double CurrentTemp { get; }
public TemperatureEventArgs(double temp) => CurrentTemp = temp;
}
<p>// 发布者中
public event EventHandler<TemperatureEventArgs> TemperatureChanged;</p><p>protected virtual void OnTemperatureChanged(double temp)
=> TemperatureChanged?.Invoke(this, new TemperatureEventArgs(temp));</p>
别用 Action<...></...>替代事件 —— 它没封装性，外部可随意调用/清空，破坏发布-订阅契约 如果真不需要 sender/e，也建议用
EventHandler（空参）而非裸委托，保持风格统一 自定义
EventArgs类应设为
public sealed，避免被意外继承篡改语义
事件机制本身轻量，但滥用会导致内存泄漏（比如忘了
-=）、调试困难（调用栈深、谁注册了谁不知道）和同步阻塞。真正关键的不是“怎么写”，而是“谁该负责触发”“谁该负责清理订阅”——这些责任边界，比语法细节重要得多。
