1. 委托的本来面目
先说个我早年写代码的经历。那时候刚学会用public、private、class，以为把方法定义好、在哪都能随心调用，这个世界就通关了。结果第一次做Web API的时候，一个按钮点击事件怎么都接不到处理逻辑，排查到最后发现是把委托和事件混着用了。从那之后，我就养成了一个习惯：凡是C#里的回调机制，先问自己三个问题——这个“方法引用”的底层类型是什么？编译之后变成了什么？运行时是单播还是多播？
C#里delegate、event、Action、EventHandler这四个东西，看起来是四个完全不同的概念，实际上一根藤上结的瓜。它们都是建立在“方法可以作为一个对象被传递”这个核心机制之上的。理解了这个点，后面的所有区别都不是死记硬背，而是顺理成章的推导。
1.1 委托的本质：把方法当成变量用
委托的本质是类型，一个继承自System.MulticastDelegate的引用类型。这么讲太拗口，换个说法：它就是“方法的签名模板”。你用delegate关键字声明一个委托，实际上是在告诉编译器：我定义了一个类型，用这个类型声明的变量，将来可以指向任何签名一致的方法。
public delegate void LogHandler(string message); public class Logger { public static void WriteToFile(string msg) { // 写入文件 } public static void WriteToConsole(string msg) { // 写入控制台 } } // 声明一个委托变量并赋值 LogHandler logAction = Logger.WriteToFile; logAction += Logger.WriteToConsole; logAction("hello");你看，定义一个方法签名，定义一个方法，把它扔进委托变量里，然后你就可以像个“方法容器”一样到处传递。调用logAction("hello")的时候，上面两个方法会依次执行。如果只执行一个，逻辑上也完全没问题。
这就像是你把一份工作交付给了一个中介——你不需要关心中介具体找谁干、怎么干、干几遍，你只管把活儿（参数）交出去，它替你安排后面的执行顺序。
1.2 委托的三要素与签名匹配
用委托之前，先把三要素立住：声明委托类型、声明委托变量、给变量绑定方法。这三步缺一个，事情就散架了。
声明委托类型决定了哪些方法能被装进来。比如LogHandler期望的参数是一个string，返回值为void。你绑定一个返回bool、参数是int的方法，编译器直接报错。这种严格性其实是一件好事——它保证了你调用委托时传参安全，不会出现参数错位、返回类型对不上的问题。
这里有个细节值得注意：委托参数的匹配规则不只是类型相同，同样是string参数，ref string、out string、普通string三个签名算不同的委托类型。我在一个项目里见过有人声明了delegate void D(ref string msg)，然后赋值时传了一个普通方法，编译期花了半小时才定位到错在哪。所以签名完全一致的匹配，字面意思上一个字节都不能差。
1.3 多播委托与执行顺序
前面logAction += Logger.WriteToConsole这一步，其实是多播委托的典型操作。C# 的委托默认支持“+”和“-”操作符，你可以用+=追加方法，用-=移除方法。底层实现的委托链，通过Delegate.Combine和Delegate.Remove来维护。
执行顺序遵循“原顺序追加，后来者排后”的规则。但是要注意，当委托链中某个方法抛出异常时，异常之后的同链方法不会继续执行。这跟事件订阅里的“一个订阅者挂了，其他订阅者全哑火”的问题同源。所以在容错要求高的场景，通常要在每个方法内部自己捕获异常，或者手动遍历GetInvocationList()逐个调用。这是在实际项目里，Action 链式调用中最容易翻车的地方。
其实，理解了委托的“包着方法签名的类型”概念，后面的event就很好理解了：event是 C# 在委托之上铺的一层访问控制封装，它让“触发”成为了一个特权，而不是人人都能上手。
2. event：委托之上的访问守门员
很多人见event的概念，直接和delegate划等号。我一开始也这么干的，导致后来维护别人代码的时候，总是看到别人可以直接调用我声明的事件——我当时写的public event EventHandler MyEvent;，在类的外部居然可以手动this.MyEvent(...)，结果逻辑绕成一团麻。
后来才明白：光声明一个public delegate字段，等于谁拿到这个实例都能直接触发；而声明成public event，外面的代码只能+=和-=订阅和退订，触发的权利被限制在了声明它的类内部。这不是语法规定的死板教条，而是一种设计保护。
2.1 编译之后发生了什么
声明一个event字段，编译器并不会真的给你生成一个普通的委托字段完事儿。它背后会生成一对访问器方法，类似于属性成员：add_xxx和remove_xxx。当外面代码写obj.MyEvent += Handler;时，实际调用到add_MyEvent；写obj.MyEvent -= Handler;时，实际调用remove_MyEvent。
而委托字段本身，往往会被编译成private的（除非你用显式实现方式呈现）。这就是为什么在类外部无法直接调用MyEvent(...)的根本原因——那个委托字段是私有或者受保护的，真正暴露出去的只有add/remove两个路口。
用代码说话：
public class Button { // 声明一个事件 public event EventHandler Click; protected virtual void OnClick() { // 类内部触发，外部只能订阅 Click?.Invoke(this, EventArgs.Empty); } public void SimulateClick() { OnClick(); } } // 外部代码 var btn = new Button(); btn.Click += (sender, e) => Console.WriteLine("clicked"); // btn.Click(...); // 这行编译不通过 btn.SimulateClick();你注意上面的Click?.Invoke这个缩写，它在编译时展开为：
var handler = Click; if (handler != null) { handler(this, EventArgs.Empty); }先取副本再判空再调用，是业界通用的安全模式，用来避免“判断非空之后、真正调用之前被另一个线程给退订”的竞态。这种细节初学者很难注意到，但在多线程UI类应用里，这种写法几乎就是硬性要求。
2.2 event 与 delegate 的边界感
既然 event 就是委托包了一层访问控制，那什么时候用 delegate，什么时候用 event？
我觉得关键不在于“我需不需要多播”，而在于“我需要暴露什么权限”。如果你只是想在类内部做回调，外部不关心，直接Action/delegate就够用。如果你想对外公开一个“别人能关注、但不能替你触发”的通知入口，就用event。
反向的一个常见场景是：在设计模式里写观察者，你如果直接把delegate作为公共字段暴露出去，任何人都能调用subject.OnChanged(...)，这等于把所有观察者全部手动触发一遍，还不会经过你类内部的业务校验。这在多人协作的项目里，是灾难级别的设计缺陷。event把触发放到拥有者手中，维护者一眼就能看出谁有权限“发信号”。
2.3 事件订阅的重复绑定问题
关于+=的一个常见坑：事件订阅不自动去重。同一个方法被绑两次，触发时它会执行两次。这个问题常出现在构造函数里订阅事件、在OnDestroy或Dispose里退订的代码中，如果生命周期写得不小心，就会重复绑定。
正确姿势是保证每次+=都有机会到-=。而且-=也会存在“如果没有订阅过就退订”的冗余操作，这在委托底层没有大碍，但能避免没必要的性能损耗。实际项目里，我看过太多人写-=只为了让自己心里安心，实际上那个事件压根儿没订阅过一次。这种代码虽不至于出错，但它是脏代码，会在将来排查问题时制造疑惑。
3. Action与Func：省掉自定义声明的武器
delegate这个原始定义方式，用久了你会发现很啰嗦——每次都要先public delegate void MyCallBack(int x, int y);，写一堆样板代码。在.NET 3.5时期，官方引入了泛型委托Action和Func，分别对应“无返回值”和“有返回值”。
3.1 Action的使用及版本演进
Action系列的签名，从Action到Action<T1, T2, ..., T16>，也就是最多支持16个泛型参数。它覆盖了绝大部分“拿参数、不返回结果”的回调场景。
public void ExecuteWithRetry(Action action, int retryCount = 3) { for (int i = 0; i < retryCount; i++) { try { action(); return; } catch { // 记录日志后重试 } } } // 使用时，直接传入方法或lambda ExecuteWithRetry(() => SaveData());使用Action的最大好处是类型安全与简洁表达。方法作为参数传入时，签名的约束不会丢失。这个特性在泛型方法里尤为明显，拿Action<T>做回调时，你可以把上下文直接通过泛型参数传进去。
3.2 Func与返回值传递
Func系列与Action相反，至少有一个返回值泛型参数，通常最后一个泛型参数是返回类型。也就是说，Func<int, string>接收一个int参数，返回一个string。
public TResult Transform<TResult>(Func<int, TResult> transform) { int rawValue = 42; return transform(rawValue); } var str = Transform(x => x.ToString()); var d = Transform(x => x * 2.0);利用模板方法模式，你可以把“变化的部分”延迟到调用方决定，而“固定的流程骨架”留在公共方法里。这个抽象思路，配合Func实在是太好用了。
3.3 Action与Func的选型原则
什么时候必须自定义delegate，什么时候直接用Action/Func？
我的经验是：如果回调方法需要一个具有业务语义的名称，比如ErrorHandler、ProgressHandler，在多个地方都要用，那就用自定义delegate。如果只是简单的回调，不值得为它设计专用类型，直接用内置Action/Func效率更高。但要注意，一旦Action参数个数超过5个，代码的可读性会急速下降——调用处只看到Action<int, int, int, string, bool>，完全不知道哪个参数对应哪个含义。这时候最好重构为自定义委托，给每个参数起有意义的名称。
提示：C# 10提供了
using别名来给委托类型定义短名称，但在公开 API 的设计中，凡是暴露给其他模块的委托，尽量用自定义delegate来维护语义。
4. EventHandler与EventArgs：事件处理的标准协议
EventHandler和EventArgs的组合，最初源自.NET Framework窗体时代的控件事件设计。UI控件需要回调携带“谁触发了事件、带了什么额外信息”，于是形成了(object sender, EventArgs e)这个固定签名。
4.1 为什么有了Action还要用EventHandler
既然Action<object, EventArgs>本质上也能承载这个签名，为什么官方非要多定义一个EventHandler委托类型？因为在设计者的预期里，事件处理应当遵循一种统一的“协议”：第一个参数表示事件源，第二个参数表示事件数据。
这个协议的意义不在类型本身，而在于约束了使用方式。如果每个组件都自己定义MyHandler(int code, string message)、MyCallback(DateTime time)，那跨组件协作的时候，订阅方需要按照每个组件的个性签名去对接。统一为(sender, e)后，界面层的事件处理代码就有了可预测的结构。熟悉WPF或WinForms的人，见到object sender的第一反应就是“我也许不需要它”，然后直接把sender忽略掉，直接处理e里的数据——这就是标准化的好处。
再者，EventHandler<TEventArgs>是泛型版本，TEventArgs约束为继承自EventArgs。这样你可以做自定义事件数据，而不必每次都声明新的委托。
public class UserLoginEventArgs : EventArgs { public string UserName { get; } public DateTime LoginTime { get; } public UserLoginEventArgs(string userName, DateTime loginTime) { UserName = userName; LoginTime = loginTime; } } public class LoginManager { public event EventHandler<UserLoginEventArgs> UserLoggedIn; public void Login(string userName) { // 登录逻辑... UserLoggedIn?.Invoke(this, new UserLoginEventArgs(userName, DateTime.Now)); } } // 订阅方 var manager = new LoginManager(); manager.UserLoggedIn += (sender, e) => { Console.WriteLine($"{e.UserName} logged in at {e.LoginTime}"); }; manager.Login("admin");上面的模式，相当于把事件的“签名”钉死成一个约定的样子，不让它飘。这带来的附加好处是：事件升级时，你可以给UserLoginEventArgs增加属性，订阅方不需要修改参数列表，兼容性极佳。
4.2 自定义事件参数的细节
构造自定义EventArgs的时候，有个习惯建议尽早养成：属性尽量定义成get只读。因为事件数据一经构造就应当是只读的，给外部修改能力只会让事件处理的顺序产生不可控的副作用。
另外，EventArgs.Empty这个静态字段在不需要传数据时使用。例如Click?.Invoke(this, EventArgs.Empty)就表示“没有额外数据”。这不是空引用，而是一个空的事件数据对象，两者差别巨大。如果用null代替，接收方判断e == null的代码会让你处处掣肘；而用EventArgs.Empty，它永远不会为空，处理方的代码可以放心直接访问属性（如果是空数据的话，属性本来就没有）。
4.3 EventHandler在异步编程里的限制
EventHandler通常是void返回类型，这在同步事件里没问题。但如果你需要异步事件通知，比如处理一个耗时操作，直接用async void会给开发者带来很大的困惑，因为异步方法内一旦有异常，可能会直接跑到线程上下文中去，导致全局崩溃而不是进入自己的异常处理逻辑。
我的做法是：在事件处理内部，自己try/catch全部包住，或者写一个AsyncEventHandler的变体委托（返回Task）。但要注意，C# 事件机制本身不感知异步返回，多播链里“等待上一个完成再执行下一个”这种写法需要手动用Func<Task>委托链来实现。这是偏离标准EventHandler的进阶玩法，日常用到的情况很少，一旦遇到，得单独设计订阅和触发机制。
5. 四者对比与接收方视角的选择
把delegate、event、Action、EventHandler放到同一个坐标里对比，是理清它们关系的最直接方式。我从“定义方式”“调用权限”“使用场景”“扩展性”四个维度做了一张表，便于读者对照：
| 类型 | 本质 | 可否多播 | 外部能否触发 | 常用场景 |
|---|---|---|---|---|
自定义delegate | 委托类型声明 | 可以 | 取决于字段可见性 | 类内部回调、模板方法 |
event包装委托 | 委托字段 + add/remove访问器 | 可以 | 不能，只能+=/-= | 对外通知（观察者模式） |
Action/Func | 预定义泛型委托 | 可以 | 取决于字段可见性 | 方法参数化、通用回调 |
EventHandler | 特定签名委托类型 | 可以 | 通常通过event包装 | UI事件、框架级事件协议 |
表中有一行很关键，“外部能否触发”这一列，实际并不是由Action或者delegate自身决定的，而是由“字段可见性”决定。你若写public Action H;，外部当然可以H();。所以真正影响触发权限的是“有没有 event 那层访问器封装”，而不是委托类型本身。
5.1 选型决策树
在日常代码里，我通常按下面的决策过程来选择：
- 如果这个回调只做内部逻辑，不对外暴露，直接
Action。 - 如果这个回调要明确返回值，用
Func<TResult>或Func<T, TResult>。 - 如果要对整个外部世界发通知，且不希望外界越权触发，声明
event EventHandler或者event EventHandler<T>。 - 如果回调逻辑是一种“错误处理协议”，比如多个模块共同遵循同一个错误处理签名（参数有业务含义），自定义
delegate命名能提升可维护性。 - 如果涉及 UI 控件或组件间的消息通知，优先用
EventHandler自定义EventArgs子类，这在框架设计中一致性好。
这个决策流程不是唯一标准，但它符合大多数 C# 项目的代码组织习惯。长期下来，回调机制的代码风格会比较统一，别人接手也容易。
5.2 反向理解：为什么 event 不能直接赋值
有些初学者试图myEvent = handler;直接给事件赋值一个新处理器，而不是用+=。这在事件上是禁止的。因为编译器生成的add/remove访问器只允许“追加”和“移除”，不允许整体替换。
这个限制的设计动机，在于避免外部代码把事件的所有订阅者清空，只留下自己一个。设想一个音乐播放器，多个插件都在订阅“播放状态变化”，某个模块如果直接player.StateChanged = Handler，其他插件的订阅就被全清了。这既不符合观察者模式，也容易引发强烈不可预期的副作用。
相比之下，delegate字段（如果是公共可见的）可以直接用=整体替换。所以从语义上看：delegate是一块可以整体重写的内存方法表，而event是只能增量维护的订阅集合。前者灵活，后者安全。
6. 实战踩坑与问题排查实录
理论反复看，不如自己踩一坑。下面这些是我在真实项目里遇到的典型问题，有些是我自己趟过的，有些是帮别人调代码时看见的，写出来给大家当避雷手册。
6.1 订阅不注销导致的内存泄漏
最常见的坑：一个短生命周期对象订阅了长生命周期对象的事件，但前者销毁后没有退订。于是长生命周期对象持有了对短生命周期对象的引用，后者永远无法被垃圾回收。
例如，在一个消息中心上挂了很多页面的事件的，页面关掉之后没有-=。你关掉一个页面，Chrome 内存不降反升，最后 OOM。
排查手段很简单，内存快照看对象数量是不是只增不减，若看到某个 ViewModel 的实例数量持续增长，基本就是事件订阅泄漏了。
规避方式可以写弱事件模式（Weak Event），或者是用Observable加CompositeDisposable统一管理订阅。实在不行，至少在生命周期终结处做-=。别嫌麻烦。
6.2 线程安全问题
在event?.Invoke(...)之前的“先拷贝判空”模式我已经提过了。但还有个隐患：如果事件处理函数内部访问了 UI 控件，而在后台线程触发，跨线程访问会直接抛异常。常规处理是Dispatcher.BeginInvoke或者SynchronizationContext.Post。
在库设计里，我不建议库内部替你封装线程切换，因为这会隐式改变调用线程的上下文。更透明的做法是：提供事件时只负责同步触发，让订阅方自己决定是否需要转到 UI 线程。这个规则一旦在库内部被打破，调试异步流程会非常痛苦。
6.3 异常处理与链路断裂
多播委托链中，某个处理方法抛异常会导致整个链中断。这意味着，前面方法已经执行完，后面方法不会执行。在实际事件通知中，一个订阅者的异常处理有 bug，可能阻止其他订阅者收到通知。
我的建议是，在事件处理函数内部做防御性编程，无论业务如何处理，最外层尽量包一个try/catch。订阅方崩溃不应影响其他订阅者，这个原则在框架级别的通知尤其重要。如果你在设计一个框架，并且希望“一个订阅者抛异常，其他订阅者照样执行”，那就需要自定义遍历调用：
public void SafeInvoke(EventHandler handler, object sender, EventArgs e) { var delegates = handler?.GetInvocationList(); if (delegates == null) return; foreach (var d in delegates) { try { ((EventHandler)d)(sender, e); } catch (Exception ex) { // 记录异常，继续执行 } } }这个模式，在 C# 里保存传播可靠性的场景很常用。代价是你得手动控制调用语义，失去了一点语法糖的轻便感，但换来的是可靠性和容错能力。
6.4 常见问题速查表
| 问题 | 排查方向 | 解决方案 |
|---|---|---|
| 事件订阅后多次触发 | 是否重复+=，是否存在生命周期重叠 | 确保+=/-=成对出现，必要时用Contains/-=去重 |
| 事件在类外部无法触发 | 使用的是event，事件触发权限被限制 | 在类内部提供protected virtual的OnXxx方法，由内部触发 |
| 方法签名对不上无法赋值 | 委托签名与目标方法不匹配 | 检查参数类型、数量、返回类型、ref/out修饰 |
| UI线程跨线程异常 | 触发线程与 UI线程不一致 | 在触发端使用SynchronizationContext或使用Control.BeginInvoke |
| 多播链中途异常导致后续不执行 | 某个处理程序抛出异常未捕获 | 订阅方内部捕获异常，或使用GetInvocationList()自定义遍历调用 |
| 事件泄漏致内存只增不减 | 短生命周期对象未退订长生命周期对象事件 | 统一管辖订阅生命周期，或改用弱事件模式 |
使用Action参数太多可读性差 | 泛型委托参数含义不明 | 使用自定义委托并给参数起语义化名称 |
async void事件处理异常难捕获 | 事件签名要求void，异步异常传播链路复杂 | 事件处理内部自行try/catch，或改用自定义Func<Task>委托 |
速查表里最值得记的一条是：无论你用哪个回调机制，先想清楚“谁拥有触发的权利，谁负责管理订阅的生命周期”。这两个问题的答案，决定了你的代码在三个月后是否还能含着泪改得动。
我个人在实际操作中最大的体会是，这四个概念本身并不复杂，复杂的是在大型应用里，回调机制和生命周期、并发、线程上下文纠缠在一起之后，问题会指数级放大。因此，每写一个事件，我都会追问：这个事件的触发方是谁？订阅方来自哪个生命周期？订阅的注销责任在谁？如果这三个问题三分钟内答得上，就可以放心写。答不上的话，先补完设计再上手，比写完了再重构省一天的时间。
