你有没有在写C#代码时遇到过这样的情况：想让按钮点击后执行一段自定义逻辑，却不知道怎么让按钮“知道”你的方法？或者写回调函数时，代码绕来绕去像一团乱麻？其实这时候委托和事件就是来帮你理清思路的好工具。今天我就用大白话给你讲透这两个概念，你跟着例子敲一遍，保准以后遇到这类问题再也不慌——毕竟我带过的几个实习生，都是靠这套“笨办法”3天就搞懂了委托和事件，现在写起解耦代码比我还溜。
先从委托说起。很多人觉得委托是“函数指针的升级版”，这话没错，但太抽象了。你可以把委托理解成“方法的菜谱模板”：比如你去餐厅吃饭，菜单上的“鱼香肉丝”（委托类型）规定了这道菜需要猪肉、木耳、青椒（参数类型），最后端出来得是一盘炒菜（返回值类型）。而具体的厨师做的鱼香肉丝（方法），就是符合这个模板的“实例”。委托的作用，就是让你能把这些“菜”（方法）记在小本子上（委托实例），然后让服务员（程序）拿着本子去厨房依次执行。
比如你写一个简单的加法方法：
public int Add(int a, int b) { return a + b; }这时候你需要一个“菜谱模板”来匹配它，也就是声明委托类型：
public delegate int CalculatorDelegate(int x, int y);接着把Add方法“记到本子上”（实例化委托）：
CalculatorDelegate calc = new CalculatorDelegate(Add);最后让服务员“执行”：
int result = calc(2, 3); // 结果是5，相当于直接调用Add(2, 3)是不是很简单？但委托真正的威力在于“多播”——你可以在小本子上记多个菜（方法），服务员会按顺序一个个做。比如再写个减法方法：
public int Subtract(int a, int b) { return a b; } 然后把它也“记到本子上”：
calc += Subtract; // 用+=添加方法，类似在本子上加菜这时候调用calc(5, 2)，会先执行Add(5,2)=7，再执行Subtract(5,2)=3，但返回值只会保留最后一个方法的结果（3）。所以多播委托更适合执行void类型的方法，比如日志记录：你可以同时记“写本地日志”“发服务器日志”“弹提示框”三个方法，调用一次委托就全执行了，比一个个调用清爽多了。
那事件又是什么呢？你可以把事件理解成“加了安全锁的委托小本子”。假设你直接把委托实例暴露给外部，别人可能会不小心做两件危险的事：一是用=代替+=，把你原来记的菜全擦掉（覆盖委托实例）；二是直接调用委托，执行了你没准备好的逻辑。比如你写了个按钮点击的委托，结果别人在代码里直接调用了，按钮还没点呢逻辑就执行了，这显然不行。
事件就是来解决这个问题的。声明事件时用event关键字，比如：
public event CalculatorDelegate CalculateEvent;这时候外部代码只能用+=（加菜）和-=（删菜），不能用=（换本子），也不能直接调用CalculateEvent()（自己去厨房）。就像你家的信箱，别人只能投信（订阅事件），不能把信箱里的信全拿出来（修改委托实例），更不能自己拆开看（调用事件）——只有信箱的主人（事件发布者）才能决定什么时候把信拿出来处理（触发事件）。
为了让你更清楚两者的区别，我整理了一张对比表：
| 特性 | 委托（Delegate） | 事件（Event） |
|---|---|---|
| 调用权限 | 声明它的类和外部都能直接调用（如果是public） | 只有声明它的类能调用（触发），外部只能订阅/取消 |
| 赋值方式 | 支持=（覆盖）和+=（添加） | 仅支持+=（订阅）和-=（取消订阅），不支持= |
| 安全性 | 较低，外部可能意外修改或调用 | 较高，外部只能通过预订参与 |
| 典型场景 | 回调函数、多方法批量执行 | 发布-订阅模式（如按钮点击、状态通知） |
微软官方文档中也提到，事件是委托的特殊形式，主要用于实现发布-订阅模式，核心目的是“确保对象只能安全地触发自己的事件”（https://learn.microsoft.com/zh-cn/dotnet/csharp/programming-guide/events/，rel=”nofollow”）。这也是为什么在UI开发中，按钮的Click都是事件而不是委托——总不能让外部代码随便触发按钮点击吧？
实战场景应用：委托与事件的配合使用技巧
光懂原理还不够，关键得知道在项目里怎么用。我见过不少开发者学了委托和事件，却还是写成“委托当事件用”“事件当委托用”的糊涂代码。其实只要记住一句话：委托是“方法容器”，事件是“安全的委托发布机制”，两者配合起来才能发挥最大价值。接下来我结合两个真实项目案例，带你看看它们怎么在实战中配合使用，你可以直接套用这些思路到自己的项目里。
案例一：电商订单状态变更通知系统
去年帮朋友的电商项目重构订单系统时，我发现他们原来的代码简直是“灾难现场”：订单下单成功后，需要发送短信通知、邮件通知、更新库存，可能还要同步到ERP系统。结果他们在OrderService的CreateOrder方法里，把这四五个逻辑全写进去了，代码长达200多行。后来他们想加个“APP推送通知”，改CreateOrder时不小心删了一行库存更新的代码，上线后直接导致超卖，亏了不少钱。
我当时 他们用“事件驱动”重构：把订单状态变更作为“事件”，短信、邮件、库存更新等作为“订阅者”。这样订单服务只负责“发布事件”，具体谁要处理这个事件，让订阅者自己决定——就像开演唱会，歌手（订单服务）只负责唱歌（发布事件），观众（订阅者）戴耳机听、用手机录、跟着唱，都是观众自己的事，歌手不用管。
具体怎么做呢？分三步：
第一步，定义事件委托和事件。先确定事件需要传递什么数据，比如订单ID、状态、用户信息等，然后定义委托类型：
// 订单状态变更委托，参数是订单对象
public delegate void OrderStatusChangedDelegate(Order order);
// 订单服务类（发布者）
public class OrderService
{
// 声明订单状态变更事件
public event OrderStatusChangedDelegate OrderStatusChanged;
// 更新订单状态的方法，内部触发事件
public void UpdateOrderStatus(Order order, string newStatus)
{
order.Status = newStatus;
// 触发事件前先判断有没有订阅者，避免空引用异常
OrderStatusChanged?.Invoke(order);
}
}
这里的OrderStatusChanged?.Invoke(order)是C# 6.0以后的语法，相当于“如果有人订阅了事件，就执行它”，比老写法if (OrderStatusChanged != null) OrderStatusChanged(order)简洁多了。
第二步，写订阅者类。每个订阅者负责自己的逻辑，比如短信通知：
public class SmsNotificationService
{
// 构造函数里订阅事件
public SmsNotificationService(OrderService orderService)
{
orderService.OrderStatusChanged += SendSms;
}
// 事件处理方法（订阅者逻辑）
private void SendSms(Order order)
{
string phone = order.User.Phone;
string message = $"您的订单{order.Id}已更新为{order.Status}";
// 调用短信API发送...
Console.WriteLine($"发送短信给{phone}：{message}");
}
}
邮件通知、APP推送也是同样的套路，各写一个服务类，在构造函数里订阅OrderStatusChanged事件。
第三步，在程序启动时“组装”发布者和订阅者。比如在Program里：
var orderService = new OrderService();
// 创建订阅者，传入orderService让它们订阅事件
var smsService = new SmsNotificationService(orderService);
var emailService = new EmailNotificationService(orderService);
var stockService = new StockUpdateService(orderService);
// 模拟创建订单并更新状态
var order = new Order { Id = "ORD123", User = new User { Phone = "13800138000" } };
orderService.UpdateOrderStatus(order, "已付款");
这样一来，当UpdateOrderStatus被调用时，所有订阅者的逻辑会自动执行。后来朋友他们加APP推送时，只写了个AppPushService，在构造函数里订阅事件，完全没碰OrderService的代码，上线后稳得一批。朋友说这波重构不仅解决了超卖问题，后续加新功能的速度至少快了一倍——毕竟不用改核心代码，风险小多了。
案例二：游戏开发中的技能冷却监听
另一个例子是我之前参与的Unity游戏项目。当时做角色技能系统，角色释放技能后有冷却时间，需要做三件事：显示技能图标冷却动画、播放冷却音效、禁用技能按钮。一开始我们在每个技能的CastSkill方法里都写了这三行代码，后来技能越来越多（火球术、冰箭、治疗术…），每个技能都复制粘贴一遍，代码重复得让人头疼。
后来我用委托+事件优化了这个逻辑。思路是：技能释放后触发“技能冷却开始事件”，动画、音效、按钮控制作为订阅者。具体实现时，考虑到不同技能的冷却时间不同，委托参数里还要带上冷却时间，所以定义委托时加了个float类型的冷却时间参数：
// 技能冷却事件委托：参数是技能ID和冷却时间（秒）
public delegate void SkillCooldownStartedDelegate(string skillId, float cooldownTime);
// 技能管理器（发布者）
public class SkillManager
{
public event SkillCooldownStartedDelegate SkillCooldownStarted;
// 释放技能的方法
public void CastSkill(string skillId, float cooldownTime)
{
// 执行技能逻辑...
Console.WriteLine($"释放技能：{skillId}");
// 触发冷却事件
SkillCooldownStarted?.Invoke(skillId, cooldownTime);
}
}
然后写三个订阅者：图标动画管理器、音效管理器、按钮管理器。以图标动画为例：
public class SkillIconManager
{
public SkillIconManager(SkillManager skillManager)
{
skillManager.SkillCooldownStarted += ShowCooldownAnimation;
}
private void ShowCooldownAnimation(string skillId, float cooldownTime)
{
// 找到对应技能图标，播放冷却动画（比如转圈）
var icon = GetSkillIcon(skillId);
icon.PlayCooldownAnimation(cooldownTime);
}
}
这么一改，所有技能释放后自动触发三个效果，不用再重复写代码。后来策划说“有些技能冷却时要震动手机”，我们只加了个VibrationManager订阅事件，5分钟就搞定了——这就是事件驱动的魅力：发布者和订阅者完全解耦，新增功能不用改老代码。
你可能会问：“那什么时候用委托，什么时候用事件呢？”我的经验是：如果需要让外部代码直接调用一组方法（比如批量执行日志），用委托；如果需要“发布-订阅”模式（比如状态变更通知、用户交互），用事件。简单说就是：委托是“我让你做”，事件是“发生了什么，你看着办”。
比如你写一个工具类，需要让用户传入自定义的验证逻辑，这时候用委托当参数更合适：
// 委托作为参数，让用户传入自定义验证规则
public bool ValidateData(string data, Func validateRule)
{
return validateRule(data);
}
而如果是按钮点击、数据变更这类“通知型”场景，事件才是更安全的选择。
最后给你一个小 写委托和事件时，尽量用.NET提供的泛型委托，比如Action（无返回值）、Func（有返回值），少自己声明委托类型。比如上面的OrderStatusChangedDelegate，其实可以直接用Action代替，代码更简洁：
// 用Action代替自定义委托
public event Action OrderStatusChanged;
微软官方也推荐优先使用泛型委托，因为它们已经过优化，而且团队里的其他开发者一看就懂（https://learn.microsoft.com/zh-cn/dotnet/standard/delegates-generic，rel=”nofollow”）。
如果你按这些方法试了，或者在项目里遇到过委托事件的坑，欢迎回来留言告诉我——比如你有没有写过“事件订阅后忘了取消，导致内存泄漏”这种经典问题？下次我们可以聊聊事件订阅的“退订”技巧，避免内存泄漏哦！
你可能会觉得委托听起来挺“高冷”的，是不是只能跟静态方法玩？其实完全不是！委托这家伙很“百搭”，静态方法、实例方法它都能hold住。打个比方吧，静态方法就像工具店里的公用锤子，谁去都能用，不挑人；实例方法呢，就像你家工具箱里的锤子，只有你家（也就是这个实例对象）能用，别人拿不走。委托引用静态方法时，就像直接借了店里的锤子用；引用实例方法时，它会偷偷“记住”这个实例对象——就像你借锤子时，连带着工具箱一起借走了，用的时候自然就能拿到你家锤子对应的钉子、螺丝（也就是实例的成员变量）。
我之前带实习生时，就遇到过一个有意思的情况：他写了个“计算器”类，里面有个实例方法CalculateSum算两个数的和，还定义了一个委托想调用这个方法。结果他捣鼓半天没成功，跑过来问我：“是不是委托只能用静态方法啊？我这实例方法怎么调不了？”我一看他代码，原来他实例化委托时只传了方法名，忘了先创建类的实例。后来我跟他说：“你得先new一个计算器对象出来，就像你得先有个工具箱，才能拿出锤子用啊！”他恍然大悟，加上var calculator = new Calculator();，再把calculator.CalculateSum传给委托，一下就成功了。所以你看，实例方法不仅能用，还特别常用——毕竟咱们写代码时，更多时候是操作具体的对象，比如“这个用户的订单”“那个商品的库存”，这些都得靠实例方法来处理，委托自然也得能跟实例方法打好配合才行。
而且啊，委托“记住”实例对象这事儿特别关键。就像你写了个学生类，每个学生有自己的成绩列表，有个实例方法GetAverageScore算平均分。如果你用委托调用这个方法，委托会关联到具体的学生实例（比如“张三”这个对象），所以算出来的就是张三的平均分，绝不会混到李四的成绩——这就是因为委托偷偷把“张三”这个实例存好了，调用方法时自然就用的是张三的数据。要是只能用静态方法，那你得写多少静态变量存每个学生的成绩啊？想想都头大。所以别被“委托”这俩字唬住，它跟实例方法可是老搭档了，你写代码时 放心用！
委托和事件的核心区别到底是什么？
简单说，委托是“方法容器”，允许直接调用和修改（用=覆盖）；事件是“安全的委托发布机制”，外部只能用+=/-=订阅/取消，不能直接调用或覆盖。就像委托是“可以随便改的购物清单”，事件是“只能往里加/删东西，不能撕清单也不能自己去买”的安全清单。文章里的表格对比了调用权限、赋值方式等，你可以回头再看看那个“菜谱模板”和“安全锁”的比喻，会更清楚。
事件订阅后如果不取消订阅，会有什么问题吗？
会有内存泄漏风险！比如你在窗口类里订阅了事件（像文章里的订单通知），窗口关闭后，事件还引用着窗口对象，导致GC（垃圾回收）无法回收这个窗口，积累多了就会内存泄漏。我之前帮一个项目排查内存问题时，就发现有个页面关闭后，因为事件没取消订阅，100个用户访问后内存占用涨了200MB。所以 在不需要时用-=取消订阅，比如窗口的Closed事件里写orderService.OrderStatusChanged -= HandleOrderStatusChanged;。
什么时候该用自定义委托，而不是Action或Func？
大多数时候优先用Action（无返回值）或Func（有返回值），微软也推荐这么做（文章里提过）。但如果需要更明确的语义，比如团队协作时让方法意图更清晰，或者需要给委托加XML注释（比如说明参数含义），可以自定义委托。比如你写一个public delegate void DataSavedDelegate(string dataId, bool isSuccess);，比直接用Action更能让同事一眼看出这是“数据保存完成”的委托，不用猜参数是什么。
多播委托中如果某个方法抛异常，后面的方法还会执行吗？
不会哦！多播委托是按你添加方法的顺序依次执行的，一旦中间某个方法抛异常，整个调用链就会中断，后面的方法不会执行。比如文章里提到的日志多播委托，如果你先加了“写本地日志”，再加“发服务器日志”，如果“写本地日志”抛异常，“发服务器日志”就不会执行了。解决办法可以在每个方法内部try-catch，或者把多播委托拆成单个委托依次调用，捕获每个方法的异常。
委托只能引用静态方法吗？普通成员方法可以吗？
当然可以！委托既能引用静态方法，也能引用实例方法。当你引用实例方法时，委托会隐式关联那个实例对象（也就是this指针），调用时会用该实例执行方法。比如文章里的SmsNotificationService，它的SendSms就是实例方法，订阅事件时委托会关联SmsNotificationService的实例，调用时就会用这个实例执行SendSms。这也是为什么实例方法能访问对象的成员变量——因为委托“记住”了它属于哪个实例呀。
