委托是描述函数签名的类型，事件是基于委托的、受封装保护的字段；事件只能在声明类内部触发，外部仅能用+=/-=订阅/取消，且需判空调用。
委托是类型，事件是字段
委托本质是一种类型定义，像 Func 或自定义的 public delegate void ClickHandler(object sender, EventArgs e);，它描述“能接收什么参数、返回什么”的函数签名。事件则是基于委托类型的字段，必须用 event 关键字声明，比如 public event ClickHandler Click;。没加 event 的委托字段只是普通可读写字段；加了之后，外部只能用 += / -= 订阅或取消，不能直接赋值或调用 —— 这是语言强制的封装保护。
常见错误现象：CS0070（“事件只能出现在 += 或 -= 的左边”）就是误写了 button.Click = handler;；或者试图在外部调用 button.Click(...)，编译直接报错。
- 委托可以单独实例化、传参、存储、调用，比如
var h = new ClickHandler(MyMethod); h(this, e); - 事件只能在声明它的类内部触发，外部只能订阅/退订
- 委托类型可公开暴露，事件字段通常
public但行为受限，更安全
定义事件的标准三步写法
不是所有委托都适合当事件。.NET 推荐遵循 sender + EventArgs 模式，尤其当你希望未来扩展事件数据时。标准写法分三步：定义委托类型 → 定义事件字段 → 在合适时机调用 Invoke（并做空检查）。
使用场景：自定义控件、状态变更通知、异步任务完成回调等需要解耦观察者逻辑的地方。
- 优先复用
EventHandler，比如public event EventHandler，避免重复造轮子DataLoaded; - 如果不需要额外参数，直接用
public event EventHandler Click;即可 - 触发前必须判空：
Click?.Invoke(this, EventArgs.Empty);，否则空引用异常；?.Invoke是 C#6+ 推荐写法，比if (Click != null) Click(...)更简洁安全
事件订阅和取消必须成对出现
事件本质是多播委托，内部维护一个调用列表。每次 += 都往里加一个方法，-= 则移除对应方法。但 C# 要求“移除的必须是之前加进去的那个委托实例”，而不是“同签名的另一个委托”。这是最容易踩的坑。
常见错误现象：用 lambda 订阅后，试图用另一个 lambda 取消，结果无效；或在不同生命周期多次订阅同一方法，导致事件被触发多次。
- 避免在循环或构造函数中反复
+=同一方法，先-=再+=不可靠，应确保只订阅一次 - lambda 表达式每次都是新实例：
btn.Click += (s,e) => Log("clicked");订阅后，无法用另一个相同 lambda 取消 - 推荐用命名方法或提前存好委托变量：
private readonly EventHandler _handler = (s,e) => ...; btn.Click += _handler; btn.Click -= _handler;
事件不是线程安全的，跨线程访问要小心
.NET 事件本身不带锁，多个线程同时订阅/取消/触发，可能引发 NullReferenceException 或漏触发。UI 控件（如 WinForms/WPF）还额外要求事件处理必须在 UI 线程执行，否则抛 InvalidOperationException。
性能影响：加锁（如 lock）会影响高并发场景下的吞吐量；而跨线程调度（如 Control.Invoke）有开销，但对 UI 来说是必须的。
- 纯后台逻辑中，若确定单线程使用，可不处理线程安全
- 不确定调用上下文时，触发前建议复制委托快照：
var handler = Click; if (handler != null) handler(this, e);，避免判空后被其他线程清空 - WinForms 中触发事件前检查
this.InvokeRequired，必要时用this.Invoke(handler, this, e)
复杂点在于：事件语义上表达“发生了什么”，但它背后是委托链表操作，既有内存模型问题，又有执行上下文约束。很多人只记得“+= 就行”，却忘了它在多线程或跨层调用时会突然失效。
