简介这份PDF聚焦C#事件处理与委托event/delegate的简明实例面向刚接触事件驱动开发的C#学习者帮助厘清委托作为类型安全方法引用的作用以及事件如何通过event关键字实现安全封装。资源以精简代码为主线先定义delegate委托类型再声明事件并用完成订阅最后在按钮点击中触发事件并调用处理方法完整呈现从声明到响应的最小可运行链路同时兼顾委托参数匹配、事件订阅语法等易错点。包体内仅含1个PDF文件大小约34KB内容密度高适合通勤或碎片时间快速阅读。目前已有534人学习下载说明该示例具备一定参考价值。跟随文中实例操作读者可掌握事件订阅与触发的基本写法理解多窗体间消息通知的底层逻辑并迁移到实际项目的界面交互与状态变更通知场景。1. 从界面卡死说起C# 事件和委托到底在解决什么问题某次做模拟项目X我用 WinForms 写“保存”按钮直接在 Click 事件里同步读写文件一触发整个窗口立刻进入“未响应”状态。当时我既不懂委托也不懂事件被前辈一句话点醒把文件处理逻辑封装成一个方法把这个方法当作参数传给耗时操作执行完了再回调。这就是 C# 委托最朴素的用途——把方法当成值传来传去让“谁在什么时候回调”变得可编程。而事件 event 是建立在委托之上的发布-订阅封装按钮只负责对外广播“保存请求”谁关心这个请求、由谁处理由订阅方决定。下面不写长篇理论把 delegate 的三种写法、event 的编译器行为以及事件泄漏、重复订阅这类常见坑一次讲透每一段都能直接抄进自己的工程里验证。这套机制解决的是“业务模块之间怎么解耦”的问题。适合刚入门 C# 的读者对照操作也适合被界面卡死、内存泄漏坑过的熟手做排查参考。搞懂这两样东西后面看任何框架源码里的回调、命令、观察者模式都会顺畅很多。2. 委托 delegate把方法当成值传递的三种写法2.1 委托的声明、实例化与调用先搞清楚最原始形态委托delegate本质上是类型安全的函数指针。它先声明一个“方法签名”然后用这个签名去引用任何匹配的方法。和 C 语言函数指针最大的区别是委托在编译期就校验签名参数个数或类型不匹配直接编译报错不会留到运行期去踩内存。// 声明一个委托类型接收两个整数返回一个整数 public delegate int CalcHandler(int a, int b); public static int Add(int a, int b) a b; public static int Sub(int a, int b) a - b; public static void Main() { // 把 Add 方法塞进委托变量 CalcHandler calc Add; // 直接像函数一样调用 int result calc(3, 2); Console.WriteLine(result); // 输出 5 calc Sub; // 换一个方法继续用 result calc(3, 2); Console.WriteLine(result); // 输出 1 }逻辑说明delegate int CalcHandler(int a, int b)并不是声明一个变量而是声明一种“类型”。后面CalcHandler calc Add才是实例化把符合签名的方法引用赋给它。调用时代码看起来和普通方法没有区别但真正执行的方法可以随时替换。参数说明这是最经典的自定义委托写法。实际项目里这种自定义委托类型现在用得越来越少因为框架内置的Func和Action已经覆盖了绝大多数场景。但理解这个原始形态仍然重要——后续事件、多播、弱事件里出现的很多行为都建立在“委托是一个对象”这个事实上。委托变量可以指向静态方法也可以指向实例方法。指向实例方法时委托内部会保存一个 Target 引用也就是那个实例对象。这个细节后面第 4 章讲事件泄漏时会再次提到委托持有 Target相当于一条从委托到对象的强引用链。2.2 内置泛型委托 Action / Func / Predicate业务代码里最常用的写法自定义委托类型虽然直观但每定义一个回调就要多写一行声明项目里很快会堆出一堆语义重叠的类型。.NET 框架内置的泛型委托解决这个问题Action没有返回值Func有返回值Predicate专做条件判断。委托类型签名典型用途ActionTvoid (T)对集合每个元素执行操作例如写入日志FuncT, TResultTResult (T)输入一个值、输出一个值例如排序键选择器PredicateTbool (T)返回真假例如ListT.FindAll的过滤条件Funcint, int, intint (int, int)等价于上面 2.1 的 CalcHandler可以直接用下面是一段能直接编译运行的示例using System; using System.Collections.Generic; using System.Linq; Listint scores new Listint { 42, 88, 75, 63, 91 }; // Action对每个元素做一件事没有返回值 scores.ForEach(s Console.WriteLine($原始分数:{s})); // Func把分数映射成等级字符串 Funcint, string toGrade s s 90 ? A : s 80 ? B : C; var grades scores.Select(toGrade).ToList(); // Predicate过滤掉不及格的 Predicateint pass s s 60; var passed scores.FindAll(pass); Console.WriteLine(string.Join(,, grades)); Console.WriteLine($通过人数:{passed.Count});逻辑说明Action适用于“有副作用、不需要返回值”的操作Func最后一个泛型参数是返回值类型前面的参数是输入PredicateT等价于FuncT, bool但语义上更明确专门表达“一个判断”。参数说明Lambda 表达式s ...在编译后会生成一个匿名方法如果 Lambda 里引用了外部变量编译器会生成一个闭包类把变量装进去。闭包类实例会被委托的 Target 引用这就是所谓的“闭包捕获”。日常写代码时Lambda 确实比方法组更省事但在需要退订事件的场景里它是坑第 4 章会专门讲。另外注意如果你写的是老版本 C#在for循环里捕获循环变量i多个 Lambda 会共享同一个i等到调用时i已经是循环结束后的值。新版本编译器已经在每次迭代生成独立变量没有这个问题但如果你是维护旧代码库这个坑仍然可能遇到。2.3 多播委托 和 - 是怎么工作的委托最容易被忽略的特性是多播一个委托变量可以同时指向多个方法调用时按添加顺序依次执行。这正是后面事件机制的地基。public delegate void Notify(string message); static void Logger(string msg) Console.WriteLine($[LOG] {msg}); static void Auditor(string msg) Console.WriteLine($[AUDIT] {msg}); Notify notify Logger; // 第一个订阅者 notify Auditor; // 追加第二个订阅者 notify(订单已创建); Console.WriteLine($调用列表长度:{notify.GetInvocationList().Length}); // 输出: // [LOG] 订单已创建 // [AUDIT] 订单已创建 // 调用列表长度:2 notify - Logger; // 移除一个订阅者 notify(订单已取消);逻辑说明实际上是Delegate.Combine的语法糖-是Delegate.Remove。调用时运行时按顺序遍历调用列表逐个执行。GetInvocationList()可以取出调用列表数组这在排查重复订阅时特别有用。参数说明这里有一个容易误解的细节——委托实例是不可变的。执行notify - Logger时并不是在原来的委托上摘掉一个方法而是生成一个新的委托实例新的调用列表里没有 Logger然后赋值给notify。如果有另一个变量还指着旧实例它看到的仍然是完整的两个订阅者。多播委托如果声明了返回值调用时的表现和直觉不同只有最后一个方法的返回值会被保留前面所有方法的返回值都被丢弃。这就是为什么事件约定俗成使用void返回值——避免“到底该听谁的”这种歧义。如果确实需要收集每个订阅者的返回值就要手动遍历GetInvocationList()逐个调用第 4 章会给出代码。3. 事件 event编译器替你在发布-订阅之间加的“锁”3.1 最小事件示例声明、订阅、触发事件是建立在委托之上的发布-订阅模型。发布者声明一个事件订阅者通过登记自己的处理方法事件触发时所有订阅者依次被调用。下面的例子模拟了一个订单服务订单创建成功后对外广播消息。using System; public class OrderService { // 事件声明基于框架的 EventHandler 委托 public event EventHandlerOrderEventArgs? OrderCreated; public void CreateOrder(string orderId) { // 业务逻辑... // 触发事件先判空没有订阅者就不做任何事 OrderCreated?.Invoke(this, new OrderEventArgs(orderId)); } } public class OrderEventArgs : EventArgs { public string OrderId { get; } public OrderEventArgs(string orderId) OrderId orderId; }订阅方的写法public static void Main() { OrderService service new OrderService(); // 对外只暴露 和 - 两种操作 service.OrderCreated OnOrderCreated; service.CreateOrder(SO-2025-001); service.OrderCreated - OnOrderCreated; } static void OnOrderCreated(object? sender, OrderEventArgs e) { Console.WriteLine($收到事件:{e.OrderId}); }逻辑说明event关键字修饰后外部代码只能做和-。不能在外部写service.OrderCreated null来清空也不能在外部直接调用service.OrderCreated(...)。这就是事件和普通公开委托字段最本质的区别发布者保留完整的控制权。参数说明第一个参数sender约定是事件源也就是发布者自己的实例这里传this第二个参数是事件数据继承自EventArgs。事件参数类建议命名为“事件名 EventArgs”这是 .NET 框架事件模式的一部分团队成员一看名字就知道怎么用。3.2 编译器的隐藏代码为什么外部只能 和 -如果你把事件声明反编译看看会发现编译器在背后生成的东西不太像表面上那么简洁。它会生成一个私有的委托字段以及两个访问器方法add_事件名和remove_事件名。外部写时实际调用的是add_XXX写-时调用的是remove_XXX。public class Compare { // A公开委托字段外部可以任意覆盖、清空、调用 public Funcint? CalcField; // B事件外部只有 add / remove 两个访问器 public event Funcint? CalcEvent; public void Fire() { CalcField?.Invoke(); CalcEvent?.Invoke(); } }外部想破坏这个类两种声明的表现完全不同Compare c new Compare(); // 公开字段可以被整体覆盖、清空、直接调用 c.CalcField () 1; c.CalcField null; var v c.CalcField(); // 事件以下操作全部编译报错 // c.CalcEvent null; // c.CalcEvent () 1; // c.CalcEvent();逻辑说明CalcEvent外部只能用和-编译阶段就把越权行为拦住了。这个“锁”的价值在于发布者可以在类内部安全地控制触发时机而订阅者只能表达“我感兴趣”不能去修改其他订阅者的注册状态。很多新人觉得事件只是个语法糖其实它防止的是“多模块互相踩脚”的架构风险。参数说明如果事件声明没有自定义访问器编译器生成的默认add/remove内部会做线程安全处理同一个事件的并发订阅不会把内部委托字段搞坏。如果你需要完全控制订阅时的行为可以像写属性一样写自定义 add/remove 访问器这在日志埋点和弱事件实现里确实用得上。3.3 EventHandler 标准模式与事件线程模型.NET 事件模式约定事件委托的签名统一为第一个参数object? sender第二个参数是继承EventArgs的数据类。框架自带的控件事件、网络回调、后台任务进度几乎都遵守这个约定。直接用EventHandlerTEventArgs就不用再自定义事件委托类型。using System; using System.Threading; public class Downloader { // 直接用框架泛型委托省掉自定义 delegate 声明 public event EventHandlerProgressEventArgs? ProgressChanged; public void Start() { for (int i 0; i 100; i 10) { Thread.Sleep(200); // 模拟耗时下载 ProgressChanged?.Invoke(this, new ProgressEventArgs(i)); } } } public class ProgressEventArgs : EventArgs { public int Percent { get; } public ProgressEventArgs(int percent) Percent percent; }逻辑说明EventHandlerTEventArgs是框架预定义的委托类型等价于delegate void EventHandlerTEventArgs(object? sender, TEventArgs e)。使用它的好处是签名统一任何熟悉 .NET 事件模式的人接手你的代码不用查文档就知道参数含义。这里必须提前说清楚一个容易被忽略的线程模型事件在哪个线程触发订阅者方法就在哪个线程执行。上面Start()里用的是当前调用线程所以订阅者ProgressChanged的回调也在同一线程。如果你把Start()丢进后台线程执行订阅者回调就会跑到后台线程此时如果回调里要更新 WinForms/WPF 界面控件就必须借助控件分派到 UI 线程否则会触发跨线程访问异常。常见的做法是后台线程触发事件订阅者收到后判断是否需要切换线程。WinForms 用Control.BeginInvokeWPF 用Dispatcher.BeginInvoke。这个线程模型不是事件机制本身的缺陷而是委托直接调用带来的自然结果。理解这一点调试“为什么事件回调里改界面会炸”这类问题会快很多。4. delegate 与 event 避坑清单事件泄漏、重复订阅与异常吞掉这一章的坑我基本都在实际项目里踩过至少一遍。事件机制本身并不难但它的隐藏引用、多播语义和异常传播方式会让一些代码“表面正常、内存疯涨”或者“只跑一半”。每条按现象、原因、解决三个步骤记录方便你直接对照排查。4.1 事件泄漏对象一直回收不掉现象后台服务每次创建订单都new一个OrderService一个全局静态管理器去订阅它的OrderFinished事件。跑一段时间后内存只增不减抓 dump 发现一堆OrderService实例无法回收。原因事件订阅建立的是“发布者指向订阅者”的强引用。发布者内部的委托字段持有了订阅者的回调方法而回调方法的 Target 就是订阅者实例。这条引用链是静态管理器 → 事件发布者实例 → 委托字段 → 订阅者方法。发布者实例被一个长期存活的对象间接引用GC 认为它“可达”所以永远不收。解决业务代码里保证每次都有对应的-。最稳妥的做法是在finally或Dispose里退订OrderService service new OrderService(); AuditManager audit new AuditManager(); service.OrderFinished audit.OnFinished; try { service.Run(orderId); } finally { // 退订必须和订阅成对出现 service.OrderFinished - audit.OnFinished; }逻辑说明-会从发布者的委托调用链里移除目标方法引用链断开后 GC 就能回收。这段代码的本质是让发布者和订阅者的生命周期解耦谁订阅谁负责退订。注意static event是最严重的事件泄漏场景因为静态事件本身常驻内存发布者实例永远不会被释放每次订阅都会把订阅者对象永久钉在内存里。遇到静态事件退订逻辑必须放在所有可能的退出路径上。4.2 重复订阅同一回调被挂两次现象一个按钮点击后事件处理逻辑执行了两次日志出现两行重复记录。代码里只写了一次但调试发现调用列表长度是 2。原因不会自动去重。同一个方法可以多次添加。更隐蔽的是如果订阅时写的是 Lambda每次执行都会生成一个新委托实例即使 Lambda 内容完全相同也会在调用列表里追加一个条目。解决订阅和退订使用同一个委托字段或者用“先移除再添加”的幂等写法public void SubscribeWithIdempotent() { // 先移除再加保证调用列表里只有一个实例 service.ProgressChanged - OnProgress; service.ProgressChanged OnProgress; }排查时把调用列表打印出来看var handlers service.ProgressChanged?.GetInvocationList(); if (handlers ! null) { foreach (var d in handlers) { Console.WriteLine($订阅者:{d.Target}, 方法:{d.Method.Name}); } }逻辑说明GetInvocationList()返回的是当前调用列表快照可以清楚看到每个订阅者的目标和方法。如果Target相同且方法名相同那就是重复订阅。注意Lambda 每次生成的委托实例 Target 不同所以如果你在代码里重新执行了一次service.ProgressChanged s ...打印会看到两个不同实例它们执行内容一样但身份不同。4.3 多播的返回值和异常后续订阅者会被中断现象一个事件被三个订阅者监听。第一个订阅者方法抛了异常后面两个没有执行。如果是带返回值的委托只有最后一个订阅者的返回值能拿到前面的结果全丢。原因运行时按顺序遍历调用列表用普通调用方式执行每个方法遇到异常直接向上抛出后面的不再执行。返回值模式下每次调用结果覆盖上一次结果所以只保留最后一个。这是委托调用链的固有行为不是 bug。解决事件签名用void订阅者各自捕获自己的异常不要把异常抛给发布者。如果确实要收集每个订阅者的结果手动遍历调用列表public void CollectAllResults() { var handlers myHandler?.GetInvocationList(); if (handlers null) return; var results new Listint(); foreach (Funcint, int single in handlers) { // 逐个调用每个结果都保留 int r single(10); results.Add(r); } }逻辑说明GetInvocationList()返回的每个元素就是单个委托可以直接强转成对应的委托类型再调用。这样每个返回值都不会丢失某个订阅者抛异常也不会中断后面的订阅者。代价是失去一次调用触发整个列表的便利性。这个场景还隐藏一个习惯问题发布者不要想着“用一个 try-catch 包住 Invoke 就算容错”。事件订阅者的异常大多意味着业务失败吞掉只会让问题延后爆发正确做法是每个订阅者内部自己处理异常。4.4 判空与竞态Invoke 之前的空引用现象多线程场景下代码写了if (Updated ! null) Updated(...)但运行期仍然抛NullReferenceException而且不是每次都能复现非常像玄学。原因判空和调用是两个独立操作。第一个线程判空通过后第二个线程把最后一个订阅者-掉了调用列表变成 null第一个线程再去调用就炸了。解决先把事件字段读取到局部变量再判断和调用public void SafeRaise() { // 只读一次后面都用这个局部变量 var handler Updated; if (handler ! null) { handler(this, EventArgs.Empty); } }逻辑说明var handler Updated读取的是那一刻的引用副本。之后另一个线程把 Updated 置空也不会影响这里已经持有的局部变量。更简洁的写法是Updated?.Invoke(...)?和Invoke在同一个表达式里编译器会自动生成读取局部副本的代码效果等价。注意局部变量只能保证“调用那一刻引用非空”如果另一个线程在读取之前就完成退订这次事件仍然会触发这是符合预期的。4.5 async void 事件处理器异常被“吞掉”现象事件处理器写成async void内部await一个耗时任务。任务抛异常后进程没有明显崩溃日志也不见程序还继续跑。原因async void方法不会像async Task那样把异常包装进返回的任务里而是直接把异常抛到当前同步上下文。在 WinForms/WPF 里有 UI 同步上下文异常会回到消息循环在控制台或后台线程没有同步上下文时异常会被交给线程池看起来就像被吞掉了。事件委托签名是void无法await所以这类处理器只能写成async void。解决把async void当作一个“入口方法”看待方法体内部必须亲自用 try-catch 接住所有异常async void OnProgressChanged(object? sender, ProgressEventArgs e) { try { await SaveRenderAsync(e.Percent); } catch (Exception ex) { Logger.Log(ex, 进度处理失败); } }逻辑说明事件处理器里一旦出现异步异常你之前熟悉的“谁调用谁捕获”规则就失效了。try-catch一定要写在async void方法体内部而不是依赖发布者或调用链上的外层。这条差点让 A同学的项目线上翻车当时没有 catch进度条一直停在半路日志里什么也没有最后借助全局异常兜底才定位到真正原因。5. 从委托字段到弱事件订阅生命周期管理进阶5.1 - 退订为什么经常失效委托实例不等价现象代码里明明写了-事件却还在触发或者第一次-有效第二次无效。最典型的场景是用 Lambda 订阅后用同一个 Lambda 写法去退订。原因Delegate.Remove的匹配规则是目标对象Target和方法MethodInfo都相等才算同一个委托实例。如果订阅时写x x * 2退订时又写一遍x x * 2这是两个不同的委托实例Target 不同移除不匹配。解决把 Lambda 保存成一个字段订阅和退订都引用同一个实例Funcint, int? savedHandler; public void Subscribe() { savedHandler x x * 2; // 生成一次记住它 source.Computed savedHandler; } public void Unsubscribe() { if (savedHandler ! null) { source.Computed - savedHandler; // 用同一个实例移除 savedHandler null; } }逻辑说明方法组写法比如service.ProgressChanged OnProgress通常情况下-能匹配成功因为编译器为同一方法生成委托时Target 和方法引用一致。但 Lambda 会创建闭包类实例每次执行都是新对象所以必须显式保存。这个规则同样适用于匿名方法和局部函数。还有一个团队协作里的真实场景如果订阅发生在类 A退订逻辑写在类 B而 B 拿不到 A 创建的那个委托实例那退订永远不生效。这种情况下最靠谱的做法是让订阅方返回“订阅令牌”退订时把令牌传回去而不是靠重新构造一个看起来相同的委托去碰运气。5.2 弱事件模式把“忘了退订”变成可容忍的事现象一个面板控件订阅了全局数据服务的事件。面板关闭后由于漏写退订全局服务通过事件委托一直引用着面板内存持续上涨。问题是代码已经上线一个个找漏写的退订不现实。原因事件持有的是强引用。如果你无法保证每个订阅点都成对退订强引用事件最终都会泄漏。弱事件模式的核心是不让发布者通过委托强引用订阅者而是用弱引用保存订阅者目标触发时如果订阅者已被回收就跳过。下面是一个简化版弱事件实现适合普通 .NET 程序不依赖 WPF 框架public class WeakEventTDelegate where TDelegate : Delegate { private readonly ListWeakReference _targets new ListWeakReference(); private readonly ListSystem.Reflection.MethodInfo _methods new ListSystem.Reflection.MethodInfo(); public void Subscribe(TDelegate handler) { _targets.Add(new WeakReference(handler.Target)); _methods.Add(handler.Method); } public void Unsubscribe(TDelegate handler) { for (int i _targets.Count - 1; i 0; i--) { if (_targets[i].Target handler.Target _methods[i] handler.Method) { _targets.RemoveAt(i); _methods.RemoveAt(i); } } } public void Raise(params object?[] args) { for (int i _targets.Count - 1; i 0; i--) { var target _targets[i].Target; if (target null) { // 订阅者已被回收顺手清理 _targets.RemoveAt(i); _methods.RemoveAt(i); continue; } _methods[i].Invoke(target, args); } } }逻辑说明WeakReference不会阻止 GC 回收订阅者对象。Raise 时如果目标已经被回收就从列表里移除避免列表膨胀。这里用反射MethodInfo.Invoke调用目标方法比直接委托调用慢所以弱事件不适合高频触发的热路径事件。提示弱事件不是银弹。它把“忘记退订”的代价转移到调用时机的不确定性上如果订阅者还活着但正好处于半初始化或半清理状态弱引用仍可能拿到目标并调用方法。所以在应用层明确知道对象生命周期的场景优先用强事件加显式退订弱事件适合“全局服务 短生命周期订阅者”这种跨度很大的架构场景。5.3 选型判断event、委托字段与接口的边界实际编码时经常有人问什么时候用事件什么时候直接暴露委托字段什么时候干脆定义接口。我的判断标准很简单按下面这张表来场景推荐方式理由单个回调例如“下载完成”Action/ 委托参数不需要多播一个订阅者就够多个订阅者监听同一次发生event编译器限制外部只能 / -语义清晰生命周期跨度大的发布者EventHandlerTEventArgs标准签名团队协作阻力最小订阅者必须实现一组相关方法接口比散乱订阅更严谨强制协议需要收集每个订阅者的返回值手动遍历调用列表避开多播返回值只保留最后一个的问题这条选型经验来自一个具体教训某跨平台系统一开始把回调全部设计成公开委托字段结果各模块互相覆盖订阅、清空订阅链整个调度全乱了。后来统一收敛成事件配合EventHandlerTEventArgs重写才把边界重新划清楚。事件提供的“只能 add/remove”约束本质上是在保护调用链的完整性。6. 事件驱动调试技巧日志探针与调用列表快照事件驱动代码最难调的地方是“看不见调用链”。断点确实能停住代码但停住之后你并不知道这个回调是谁挂进来的、调用列表里还有谁。我现在的习惯是在基类里预留一个探针订阅者排在所有业务订阅者之后每次事件触发都记录触发时间和参数快照。这个办法比反复打断点高效得多。public static class EventProbe { // 把探针挂到任意事件上排在业务订阅者之后 public static void AttachTEventArgs(EventHandlerTEventArgs source, string name) where TEventArgs : EventArgs { source (sender, e) { Console.WriteLine($[probe] {name} fired at {DateTime.Now:HH:mm:ss.fff}); Console.WriteLine($[probe] sender{sender?.GetType().Name}, data{e}); }; } }逻辑说明探针日志不会改变业务行为只记录触发时间、事件源类型和事件参数。如果同一个事件触发两次但代码里只看到一处把GetInvocationList()打出来就能看到是不是基类初始化里也订阅了一次。排查内存泄漏时我通常用弱引用来验证退订是否生效先创建订阅者实例只保留一个弱引用触发 GC 后看实例有没有被回收。如果实例还活着说明事件链上仍然有强引用指向它顺着GetInvocationList()打印出来的 Target 类型去查是谁持有。最后一条尽量保持事件参数不可变。事件数据类设计成只有 getter避免订阅者之间通过共享参数对象互相干扰。这也是 .NET 事件模式的隐含约定。我这个习惯是被一次“两个订阅者改同一个事件参数导致顺序不同结果不同”的定位过程逼出来的从那以后所有事件参数类一律只读。希望帮到你。本文还有配套的精品资源点击获取