做C#开发这些年，被问到最多的一个问题就是“委托到底有几种写法”。网上资料不少，但大多只罗列语法，不讲背后的设计逻辑。新人看完常常一脸懵：明明能干同一件事，为什么要整出四种姿势？每种写法到底解决了什么痛点？性能上有区别吗？项目里该用哪个？
这篇文章把 C# 里委托的四种实现方式从原理到实战一次讲透。四种方式分别是：delegate 关键字声明具名委托、匿名方法、Func/Action 内置泛型委托、Lambda 表达式。文章会沿着“为什么需要这种方式 → 底层发生了什么 → 实际项目里怎么选”的脉络走，配合完整的代码示例和避坑清单，帮你在几分钟内建立清晰的决策框架。
这篇文章适合三类人：刚学完 C# 语法、想搞懂委托本质的初学者；写了两三年业务代码、想优化事件和回调设计的进阶开发者；以及准备面试、需要系统梳理委托知识点的求职者。阅读前最好对类、接口、泛型有基础认知，如果这些还不熟，建议先补一下再看。
1. 委托的核心思想：把方法当作参数传递
很多初学者第一次接触委托时，最大的障碍是思维转换。变量存的是值，int 存数字、string 存文本，这些都好理解。委托存的是什么？是一个方法的“引用”，或者说是一个方法的“地址”。有了这个地址，你就可以把方法像数据一样传来传去，在合适的时机再调用它。
举一个生活化的例子。你开了一家餐厅，需要一个供货商每天送菜。你不需要自己知道菜从哪个农场来、走哪条运输路线，你只需要拿到一个“送菜服务”的接口，到时候有人把菜送上门就行。这里“送菜服务”就是委托，具体由哪家供货商实现，你根本不用关心。
对应到代码里，委托就是“方法的契约”。它定义了方法的返回值类型和参数列表，至于方法体里具体做什么，交给调用方去填充。这种“把行为参数化”的能力，是事件、回调、LINQ、异步编程等一系列高级特性的基石。
为什么委托有四种写法？本质上是因为 C# 语言在迭代过程中，不断想办法让“方法参数化”这件事写起来更省事。delegate 关键字最原始，匿名方法省掉了单独声明方法，Func/Action 省掉了自定义委托类型，Lambda 则把匿名方法的语法进一步压缩成了表达式。四种写法能力上等价，但代码的简洁度和可读性逐步提升。
2. 第一种实现：delegate 具名委托
在.NET Framework 1.0 时代，C# 只有这一种委托写法。它的完整流程分三步：声明委托类型、实例化委托、调用委托。
// 第一步：声明委托类型 public delegate void OrderHandler(string orderId); // 第二步：定义一个匹配的方法 public void ProcessOrder(string orderId) { Console.WriteLine($"处理订单：{orderId}"); } // 第三步：实例化并调用 OrderHandler handler = new OrderHandler(ProcessOrder); handler("A10001");这段代码里，OrderHandler就是委托类型。声明时用delegate关键字，后面跟返回值、委托名和参数列表。任何返回值是 void、只有一个 string 参数的方法，都可以赋值给这个委托。
委托实例化有两种语法。上面写的是传统写法，用new关键字包装。其实从 C# 2.0 开始，可以直接方法组转换：
OrderHandler handler = ProcessOrder;两种写法编译后的 IL 代码完全一致。方法组转换只是编译器提供的语法糖，省掉了类型名书写。不要觉得直接赋值是“偷懒”，这是官方推荐写法，代码更干净。
委托调用也有两种方式。直接调用handler("A10001")和调用handler.Invoke("A10001")等价。有一点需要特别注意，Invoke是同步调用，如果委托包装的方法耗时很长，调用线程会一直阻塞。后续要考虑异步场景时，委托也要配合 Task 或异步方法使用。
再说说委托的特点。委托是引用类型，继承自System.MulticastDelegate，而后者继承自System.Delegate。这意味着委托自带一个能力：多播。一个委托实例可以同时指向多个方法，调用时按顺序依次执行。
OrderHandler handler = ProcessOrder; handler += SendNotify; handler += WriteLog; handler("A10001");用+=添加方法，用-=移除方法。多播委托的内部结构是一个调用列表，每个节点封装一个方法。调用时从链表头部遍历到尾部。这个机制是 C# 事件模型的底层基础，后面讲事件时还会深入。
多播委托有两个关键限制需要记住。第一，多播委托的返回值必须是 void。如果委托有返回值，+=之后只会得到最后一个方法的结果，前面的返回值全部丢弃，容易造成逻辑混乱。第二，多播委托如果某个方法抛异常，整个调用链中断，后面的方法不会执行。这点在事件处理中尤其重要，某个订阅者的异常会影响其他订阅者。稳妥做法是在方法内部自行捕获异常。
具名委托最大的优势是语义清晰。委托类型有一个响亮的名字，比如OrderHandler、DataReceivedHandler，读代码的人一眼就能看出意图。这在公共 API 设计、框架开发、领域建模中非常有价值，相当于给“方法参数”起了个业务名字。
但具名委托的缺点同样明显。你可以想象一下，如果一个类里定义了十几个委托类型，每个都对应不同的方法签名，代码会变得相当冗长。而且为了一个简单的回调，你不得不先写一个独立方法，再实例化委托，再调用，链路很长。这就是后面几种写法要解决的问题。
3. 第二种实现：匿名方法
匿名方法在 C# 2.0 引入。核心价值是：不再需要为委托单独定义一个命名方法。你可以把方法体直接内联在委托实例化代码里。
OrderHandler handler = delegate(string orderId) { Console.WriteLine($"处理订单：{orderId}"); }; handler("A10001");delegate关键字在这里不再声明类型，而是直接创建一个方法体。编译器会在后台生成一个私有方法，并把这块代码搬进去。你节省了“先写一个方法，再绑定它”的步骤。
匿名方法有个好用的特性：可以捕获外部变量，这也就是闭包（Closure）。
string prefix = "订单-"; OrderHandler handler = delegate(string orderId) { Console.WriteLine(prefix + orderId); };这里prefix是外部局部变量，但匿名方法内部可以访问它。编译器会把捕获的变量“提升”到一个生成的类里，保证变量的生命周期与委托一致。即使方法已经返回，委托仍然能访问当时的变量值。
这个特性极大增强了委托的表达力。在早期 C# 版本里，这是实现回调逻辑最灵活的手段。不过匿名方法有两个让人不舒服的地方。
一是语法仍然啰嗦。delegate关键字再加上参数列表，整段代码看起来仍然不够轻量。二是delegate关键字在这里的意义容易混淆。初学者经常分不清“声明委托类型”和“创建匿名方法”两种用法，因为都出现了delegate。这其实是 C# 早期设计上的一个历史包袱，算不上多优雅。
再补充一个细节：匿名方法无法在声明处直接移除。如果你用+=把匿名方法添加到多播委托中，又想用-=移除它，必须事先把匿名方法存到一个变量里。
OrderHandler handler = null; OrderHandler temp = delegate(string orderId) { Console.WriteLine(orderId); }; handler += temp; handler -= temp;这样写麻烦但可行。现实中，很少有人把匿名方法存下来再移除。大多数场景是一次性回调，不需要取消订阅。如果要频繁订阅和退订，还是应该使用具名方法。
从 C# 3.0 开始，Lambda 表达式几乎完全取代了匿名方法。但底层机制一脉相承，理解匿名方法，是理解 Lambda 的地基。
4. 第三种实现：Func 与 Action 内置泛型委托
上面两种写法有一个共同痛点：每个业务场景下，你都可能需要自定义一个委托类型。如果只是临时需要一个“接收一个 int 返回 bool”的回调，难道也要专门声明一个Predicate类型的委托吗？答案是：.NET 团队早就考虑到了这一点，所以他们在 .NET Framework 3.5 中提供了泛型委托 Func 和 Action。
Func 代表有返回值的委托，Action 代表无返回值的委托。它们都提供了大量泛型重载，覆盖了常用参数组合。
// 无参数，返回 int Func<int> func1 = () => 42; // 一个 int 参数，返回 string Func<int, string> func2 = x => x.ToString(); // 两个参数，第一个 int，第二个 string，返回 bool Func<int, string, bool> func3 = (x, s) => s.Length > x; // 无参数，无返回值 Action action1 = () => Console.WriteLine("执行"); // 一个参数，无返回值 Action<string> action2 = s => Console.WriteLine(s);Func 类型最多支持 16 个参数，最后一个泛型参数是返回值类型。Action 同样最多支持 16 个参数，但没有返回值。实际开发中，参数超过 5 个的情况已经很少见，真遇到那么多参数，大概率需要重构了。
有了 Func 和 Action，绝大多数场景下你都不需要自定义委托类型了。例如集合的Where方法需要Func<T, bool>，Select需要Func<T, TResult>，事件的订阅者用Action<T>做参数。系统自带、类型安全、泛型复用，这是它们三大核心优势。
这里我要专门提一个面试中频繁出现的问题：Func 和 Action 可以替代自定义委托吗？
答案是不能完全替代。区别有两个层面。第一，语义层面。自定义委托可以起一个业务名，比如OrderHandler直接表达“订单处理”的意图，而Func<string, void>只能告诉你签名，传达不出业务含义。在领域驱动设计中，显式命名的委托类型本身就是一种文档。第二，灵活性层面。自定义委托可以加 XML 注释，可以附加特性，可以做更复杂的约束；Func 和 Action 则本质上只是预定义好的多个重载类型，没有商量的余地。
所以实际项目里的策略是：临时回调、集合操作、简单事件处理，优先用 Func / Action；公共 API、框架代码、业务语义强烈的场景，自定义委托更合适。这个策略在团队协作中也很重要，毕竟别人读你代码时，看到一个OrderHandler比看到一个Func<string, string, bool>要舒服得多。
写到这里，你应该注意到上文示例里已经大量使用了 Lambda 表达式来创建 Func 和 Action。没错，Func/Action 和 Lambda 是黄金搭档。但 Func/Action 本身并不依赖 Lambda，你也可以传递具名方法：
Func<int, int> square = SquareMethod; public int SquareMethod(int x) { return x * x; }这是完全合法的。所以不要把“Func / Action”和“Lambda”划等号，它们是两码事。一个是委托类型，一个是创建委托实例的语法。
5. 第四种实现：Lambda 表达式
Lambda 表达式是 C# 3.0 引入的，是匿名方法的直接升级版。它的设计目标只有一个：让创建委托实例的代码最短、最清晰。从语法上，Lambda 去掉了delegate关键字，改用=>符号连接参数和方法体。
Func<int, int> square = x => x * x; Action<string> print = s => Console.WriteLine(s);这一行代码干的事，用匿名方法要写三行，用具名方法要写一个完整方法，用传统 delegate 写法要声明类型加写方法再加实例化。Lambda 把语法成本压到了极限。
Lambda 有两种形式。表达式 Lambda 只有一个表达式，没有花括号，隐式返回表达式结果。语句 Lambda 有花括号，内部可以写多条语句。
Func<int, int> square = x => x * x; // 表达式 Lambda Action<int> print = x => { int result = x * 2; Console.WriteLine(result); }; // 语句 Lambda大多数情况下优先使用表达式 Lambda。它更短、更纯粹，而且可以被编译器进一步优化。比如在表达式树（Expression Tree）场景中，只有表达式 Lambda 才能被编译成表达式树，语句 Lambda 不行。这涉及 LINQ 到 SQL 的转换机制，后面可以单独聊。
Lambda 的参数类型通常可以省略，编译器会根据委托类型推断。比如Func<int, string>里，x自动推断为 int。如果多个参数，用逗号分隔。单参数可以省略圆括号，但建议保持一致，都带括号更清楚。
Func<int, int, int> add = (a, b) => a + b; Func<int, int> negate = n => -n;Lambda 同样支持闭包捕获。这和匿名方法的闭包机制完全一致，编译器生成的包装类可以被多个 Lambda 共用。这里有一个非常经典的陷阱：循环变量捕获。
List<Action> actions = new List<Action>(); for (int i = 0; i < 5; i++) { actions.Add(() => Console.WriteLine(i)); } foreach (var action in actions) { action(); }这段代码在 C# 5.0 之前输出五个 5，在 C# 5.0 之后输出 0、1、2、3、4。原因是 C# 5.0 把 foreach 迭代变量改为每次循环生成一个新变量，for 循环的迭代变量则不受影响。如果 for 里有闭包，需要手动复制副本：
for (int i = 0; i < 5; i++) { int copy = i; actions.Add(() => Console.WriteLine(copy)); }这个坑在异步回调里尤其常见。启动多个任务，每个任务里捕获循环变量，结果发现所有任务拿到的都是最终值。问题根源不是异步，而是闭包的捕获语义。这一点强烈建议新手在纸上画一遍变量生命周期，比死记结论要牢固得多。
Lambda 还有一个小语法点，叫弃元。当委托类型参数很多，但方法体只用其中一部分时，可以用下划线丢弃：
Func<int, string, bool> checkHandler = (_, _) => true;从 C# 9.0 开始，Lambda 支持这个写法，能让签名更精练。不过要注意，两个下划线是独立参数，编译层面并不冲突。
使用 Lambda 时，表达式树是一个绕不开的话题。所有的 LINQ to Entities （也就是数据库查询）都依赖表达式树。Lambda 表达式在 LINQ 中可以被编译为委托，也可以被转换为表达式树。编译器根据上下文自动选择。这一点初学者理解起来有难度，但不需要着急，先把委托层面的 Lambda 吃透，后面再研究表达式树。
6. 委托的底层机制与性能考量
四种写法看起来只是语法层面的差异，编译后的 IL 代码实际上高度相似。但细节处有区别，这些区别直接关系到性能，值得展开聊。
先看底层结构。任意一个委托实例在 .NET 内存中都是一个对象，包含三个关键字段：方法地址、目标对象、调用列表。方法地址是指向包装方法的指针，目标对象是方法所属的实例（静态方法则为 null），调用列表用于多播。当你调用委托时，运行时本质上是在做一次方法指针的间接调用，而不是像普通方法那样直接跳转到固定地址。这个间接调用会带来极小的性能开销，但对于绝大多数业务场景可以忽略。
再看两种常见实现的差异：Lambda 和匿名方法都将代码块提取为编译器生成的私有方法。区别在于，如果 Lambda 没有捕获任何外部变量，编译器会生成一个静态方法，并且委托实例可以被缓存。如果捕获了外部变量，编译器会生成一个闭包类，每次执行都会创建一个新实例，内存分配随调用次数线性增长。
这个差异在性能敏感的场景里非常明显。比如一个每帧执行的游戏更新逻辑，如果有闭包捕获，可能会造成频繁的 GC 压力；没有捕获的静态 Lambda，则能做到几乎零分配。现代 .NET 编译器已经对常见的无捕获 Lambda 做了静态缓存优化，你只需要养成习惯：能静态就不用闭包。
再谈异步。经典 .NET Framework 中委托提供了BeginInvoke和EndInvoke方法，用来做异步调用。但在 .NET Core / .NET 5+ 中，这两个方法被标记为不支持。原因是异步模型已经向Task/Task.Run/async/await转移。现在遇到耗时委托，正确做法是：
Func<string> heavyWork = () => DoSomething(); string result = await Task.Run(heavyWork);这不仅跨平台兼容，而且更符合现代异步编程范式。你不需要、也不应该依赖BeginInvoke这样的老式异步。
委托还有一个容易被忽略的细节：委托的相等性比较。两个委托实例相等，前提是它们引用同一方法、同一目标对象。Lambda 创建的委托，哪怕方法体一模一样，也是两个不同对象的实例，Equals返回 false。这在事件退订时是个坑，如果你用局部变量添加事件处理器，后来用同样的 Lambda 代码去退订，是失败的，因为没有指向同一个委托实例。切记：事件加 Lambda 容易，退订麻烦，唯一可靠方法是先存委托实例，前面匿名方法一节里已经演示过。
多播委托的调用性能也要注意。如果调用列表里有几十个方法，每次调用都要依次遍历。对于事件这种高频触发场景，如果订阅者很多且执行速度参差不齐，整体延迟会被最慢的订阅者拖累。业界常见的优化思路是异步发布事件、批量通知或使用轻量级消息聚合器，但那是另一个话题了，这里点到即止。
最后补充一个关于异步委托的底层细节：编译器并不会自动为异步 Lambda（async Lambda）生成特殊处理。async关键字只是让编译器把方法体转换为状态机，委托本身还是同步调用逻辑。这意味着你委托一个async Task方法时，调用方拿到的是Task，必须等待或继续处理，不能指望委托替你管理异步生命周期。理解和掌握 Task 的传播机制，是写出可靠异步代码的前提。
7. 常见问题与避坑实录
这块我整理了实际开发中最常遇到的八个委托问题，基本覆盖了新人到中级开发者踩坑的重灾区。
| 问题现象 | 根本原因 | 解决方案 |
|---|---|---|
| 事件退订时用相同 Lambda 代码却失败 | Lambda 每次创建不同实例，相等性比较失败 | 用字段或局部变量保存委托实例再退订 |
| for 循环内捕获迭代变量，异步回调全拿最后值 | 闭包捕获的是变量本身，不是值拷贝 | 循环体内用局部变量拷贝 |
| 多播委托某个方法抛异常，后续方法不执行 | 调用链中断机制如此 | 方法内部自行捕获异常 |
| 委托参数很多，Lambda 签名写着难受 | 参数列表过长，设计有问题 | 拆分组装参数，用自定义类型承载 |
| Func/Action 在公共 API 中表达力不足 | 类型只有签名没有语义 | 公共 API 中使用具名委托 |
| 委托对象反复创建，内存压力大 | 闭包捕获外部变量导致分配 | 尽量用静态 Lambda，减少闭包使用 |
| async void 类型的委托，异常难捕获 | 异步方法不做异常传播 | 用 Func 或 Action 代替 |
BeginInvoke在 .NET Core 环境报错 | API 已不推荐，平台层面不支持 | 迁移到 Task.Run 模型 |
逐一解释其中三个最典型的。
**第一个是事件退订。**很多初学者写事件订阅时直接用 Lambda，后来要取消订阅，又写了一遍一模一样的 Lambda，结果事件还在触发。前面讲过原因了，Lambda 实例每次都是新对象。解决方案很简单，从一开始就定义一个委托字段：
private Action<string> _handler; public void Subscribe() { _handler = msg => Console.WriteLine(msg); someEvent += _handler; } public void Unsubscribe() { someEvent -= _handler; }这个坑在 UI 编程中尤其危险，反复订阅不退订会导致内存泄漏，界面卡顿甚至崩溃。推荐做法是在订阅时检查是否已订阅，在 Dispose 中统一退订。
**第二个是循环变量捕获。**C# 5.0 改进的是 foreach，for 没有改进。所以只有一个建议：写 for 循环时永远把循环变量复制到局部变量，再在 Lambda 里使用。这个习惯能在多线程环境中救你一命。
**第三个是异步 Lambda 异常处理。**如果你用了async void类型的委托，方法内的异常会直接抛出到同步上下文，可能导致进程崩溃。正确做法是使用Func<Task>类型的委托，让异常可以等待和捕获，还可以进一步使用async/await处理。
Func<Task> asyncAction = async () => { await Task.Delay(1000); throw new InvalidOperationException("出错"); }; try { await asyncAction(); } catch (Exception ex) { Console.WriteLine($"捕获：{ex.Message}"); }这比无脑async void安全得多。尤其事件处理器里，能用async void的场景非常有限，推荐优先用 async Task 模式。
**第四个是性能陷阱。**很多人以为委托性能差，其实在现代 .NET 里运行时已经做了大量优化。真正的性能问题常常出现在闭包分配上。如果你既要闭包又要性能，一个妥协方案是手动把需要捕获的变量放进一个自定义类，然后复用这个类实例。这样做虽然代码不优雅，但在极端热路径中能显著减少分配次数。
还有个关于委托与方法的趣事：当你把委托作为参数传入方法时，编译器会做隐式的实例化和转换。比如下面的写法完全合法：
public void Exec(Func<string, string> formatter) { Console.WriteLine(formatter("test")); } Exec(FormatString); public string FormatString(string input) { return input.ToUpper(); }FormatString方法组被隐式转换为Func<string, string>。如果方法重载了，方法组还会涉及重载解析。用法上很简单，但理解起来需要一点经验。
再说一个经常被忽略的细节：委托的协变和逆变。从 C# 4.0 起，泛型委托支持协变和逆变。Func<Derived>可以赋给Func<Base>（协变），Action<Base>可以赋给Action<Derived>（逆变）。这在处理继承层次时很有用，不过实践中用得不多，了解即可。
8. 最后再分享一个心得
委托这四种写法，用一句话概括就是：同样的能力，不同的表达成本。delegate 具名委托提供最强语义和最好的自文档性，匿名方法解决了方法独立命名的问题，Func/Action 消灭了委托类型定义的大部分负担，Lambda 则把语法压缩到了极致。不存在哪个最好，只存在哪个合适。
我个人在实际开发中的一个习惯是：写公共库和框架代码时，尽量用具名委托，让 API 阅读者从类型名就能看出意图；写业务逻辑和 UI 回调时，用 Func/Action 加 Lambda，最大程度缩短代码行数；只有当事件退订或需要多播时，才显式保存委托实例再操作。这种取舍标准，既能保证代码可读性，又不牺牲表达力。
还有一个小建议给初学者：不要急着背语法，先理解委托本质上是“方法的引用”。理解了这一点，四种写法就能在你的脑海里统一成一个概念，剩下的只是不同时代的语法糖。遇到任何回调、事件、LINQ 查询的需求，你会自然地选择最合适的那一种。扎实掌握委托机制，后面学事件、表达式树、async/await 都会顺畅很多。
