简介面向C#初学者的实例讲解资料聚焦委托与事件两大核心概念。C#委托是类型安全的方法引用事件则基于委托实现对象间通知文中从delegate定义、EventHandler预定义委托讲起逐步说明如何用event关键字声明事件、使用“”订阅处理方法并在按钮事件中触发自定义事件最终由处理方法完成响应。资源包内为单个PDF文件大小仅34KB篇幅精简适合碎片时间阅读或作为复习速查。已有534人浏览学习对入门者具有一定参考价值。示例给出了完整可运行的C#窗体代码在Form1构造函数中将d方法绑定到事件abutton1_Click内触发a(ss)调用d并显示消息框清晰展示了“声明—订阅—触发—处理”的完整链路。读者按示例操作即可理解委托与事件在真实UI程序中的协作方式并为多窗体通信、组件解耦等扩展场景提供思路基础。1. 先说结论C#事件处理和委托是解耦的钥匙理解这两个概念比记住语法更重要很多人在C#窗体程序里写过这样的代码A窗体要通知B窗体刷新数据直接把B窗体的公共方法拿来调用结果界面耦合得厉害改一处动全身。后来某位开发者把调用改成事件触发代码清爽了一个量级。这篇笔记围绕C#事件处理和委托event delegate的实例展开用最简单可运行的方式说明声明、订阅、触发的完整链路再补充实际项目中真正会踩的坑。适合刚学完C#语法、想搞懂事件机制的新手也适合写了几个月窗体程序但一直对event和delegate边界模糊的开发者。读完能自己搭出一个跨窗体通知的骨架知道触发时为什么要判空知道多线程下为什么会报“线程间操作无效”。先建立正确的心智模型再动手写代码后面就顺了。2. 把委托和事件分开看为什么裸委托在窗体程序里是隐患2.1 委托一个类型安全的函数指针能装一个也能装一串委托的本质是“方法的类型”。int能声明整数变量string能声明字符串变量委托类型能声明“方法变量”。定义委托语法很简单public delegate void NotifyHandler(string message);这句声明定义了一种方法形状返回值void参数一个string。之后任何“返回void、只有一个string参数”的方法都可以被这个委托引用。声明的关键是签名完全一致不一致编译就报错这就是“类型安全”的含义。NotifyHandler _handler; _handler ShowMessage; // 方法名直接赋值 _handler(hello); // 通过委托变量调用方法 void ShowMessage(string msg) Console.WriteLine(msg);逻辑说明第一行声明委托变量第二行把ShowMessage方法“装进”委托变量第三行通过委托调用。参数说明委托变量可以指向实例方法、静态方法、甚至匿名方法和Lambda。实际项目中常用的是多播——用把多个方法挂到同一个委托变量上NotifyHandler _handler MethodA; _handler MethodB; _handler(多播测试);此时调用一次委托MethodA和MethodB按订阅顺序依次执行。多播委托返回值只取最后一个方法的结果所以委托设计上一般用void返回这是经验的总结。2.2 事件对外只开放“订阅”和“退订”触发权锁在类内部事件可以理解为“受限的委托字段”。声明方式加上event关键字public event NotifyHandler NotifyOccurred;与直接public委托字段相比区别很关键外部代码可以对事件使用订阅、-退订但不能直接赋值更不能在类外部触发。下面这段代码在类外触发会被编译器拦住// 下面两行都编译不过 someObject.NotifyOccurred AnotherMethod; someObject.NotifyOccurred(外部直接触发);编译器报错类似“事件只能出现在或-的左边”。这个限制不是形式主义事件源类掌握触发时机订阅者只能被动响应双方通过事件契约解耦。某位开发者早期图省事用public委托字段做跨窗体通知结果别的窗体在任意时刻都能触发对方的事件调试时根本分不清是谁调用的。改成event之后触发入口收窄到事件源类内部问题定位快得多。2.3 选型回调、接口还是事件按场景定委托和事件不是互斥方案。委托适合“方法作为参数传入”把行为注入到另一个方法中典型是List的Where、Select。事件适合“某个动作发生后通知外部”典型是按钮点击、数据加载完成、客户端断开连接。中间还有接口方案适合“订阅方必须实现一组固定方法”的时候。方案适用场景优点注意点委托回调参数、方法注入灵活、类型安全慎用public字段外部可任意触发事件状态变化通知、跨窗体通信触发权受控、解耦好需要判空、注意退订接口固定行为契约结构清晰订阅方必须实现全部方法从工程习惯来看窗体程序里做“某某窗体通知某某窗体”优先用事件做通用工具库、需要调用方传入逻辑时用委托。这个选择没有绝对的对错但从维护成本看事件在解耦上的收益通常更大。3. 完整实例拆解从最小可运行代码到跨窗体通知3.1 最小实例事件声明、订阅与触发的完整骨架先看一段来自原笔记的简洁实例它用最简单的方式演示了事件处理的核心环节。代码在WinForms环境下运行窗体上有一个按钮public delegate void CustomHandler(string s); // 自定义委托签名void(string) public partial class Form1 : Form { public event CustomHandler NotifyEvent; // 声明事件类型是上面的委托 public Form1() { InitializeComponent(); NotifyEvent HandleNotify; // 在构造函数中订阅事件 } private void button1_Click(object sender, EventArgs e) { MessageBox.Show(即将引发事件); NotifyEvent?.Invoke(ss); // 触发事件带上字符串参数 MessageBox.Show(事件处理完毕继续执行后续逻辑); } public void HandleNotify(string message) { MessageBox.Show(d. message); } }逻辑说明按钮点击后先弹出“即将引发事件”接着触发NotifyEvent事件绑定的HandleNotify方法被同步调用弹出“d.ss”然后回到按钮点击方法继续执行最后弹出“事件处理完毕”。订阅动作放在构造函数里意味着窗体一创建事件就绑好了。这里用?.Invoke替代直接调用是为了在无人订阅时不抛空引用异常。参数说明委托CustomHandler接收string参数触发时传入“ss”符合委托签名。如果想传多个数据可以继续加参数比如void CustomHandler(string senderName, int code)同步修改触发处的实参即可。但这个写法有个副作用事件处理和触发在同一个线程里同步执行后续会说到如何在异步场景中处理。3.2 从单窗体到跨窗体子窗体通知父窗体刷新的常见做法实际项目里最常见的是跨窗体通知。现在做一个带标准EventHandler签名的版本。标准委托是public delegate void EventHandler(object sender, EventArgs e)事件携带两个参数——发送方和事件数据。下面用子窗体去通知父窗体刷新列表// 子窗体类 public partial class ChildForm : Form { // 声明标准事件使用系统定义的事件委托 public event EventHandler DataSaved; private void btnSave_Click(object sender, EventArgs e) { // 保存业务数据省略 MessageBox.Show(数据已保存); // 触发事件把当前窗体作为sender传入 DataSaved?.Invoke(this, EventArgs.Empty); } }父窗体一侧的订阅// 父窗体中打开子窗体的位置 var child new ChildForm(); child.DataSaved RefreshListView; // 订阅子窗体事件 child.Show(); private void RefreshListView(object sender, EventArgs e) { // 从数据库重新加载数据 LoadDataToListView(); }逻辑说明子窗体保存按钮点击后保存自身业务数据然后触发DataSaved事件父窗体因为在打开子窗体时订阅了这个事件所以自动执行RefreshListView方法完成列表刷新。整个过程子窗体不直接持有父窗体的引用两者只在事件上关联。参数说明sender传的是子窗体实例this这样父窗体在处理时能通过(ChildForm)sender拿到来源对象做强类型操作。这里用EventArgs.Empty作为空数据没有需要传递的信息。如果想带数据替换为public event EventHandlerDataSavedEventArgs DataSaved;自定义事件参数类继承EventArgs并携带信息。3.3 从string参数到自定义事件参数携带结构化数据的标准做法当事件需要传递的信息超过一个简单字符串工程上习惯是定义专门的事件参数类public class DataSavedEventArgs : EventArgs { public string FileName { get; } public long FileSize { get; } public DataSavedEventArgs(string fileName, long fileSize) { FileName fileName; FileSize fileSize; } } public partial class ChildForm : Form { // 泛型事件委托携带自定义参数 public event EventHandlerDataSavedEventArgs DataSaved; private void btnSave_Click(object sender, EventArgs e) { var args new DataSavedEventArgs(report.xlsx, 20480); DataSaved?.Invoke(this, args); } }订阅方接收时从事件参数里取值private void HandleDataSaved(object sender, DataSavedEventArgs e) { statusLabel.Text $已保存{e.FileName}大小{e.FileSize}字节; }逻辑说明自定义事件参数类让事件携带的信息从“裸字符串”变成了“有名字的字段”调用方不再靠记忆参数顺序而是通过属性名取值。这个模式在.NET类库中大量使用是最值得养成的习惯。参数说明事件参数类命名统一以EventArgs结尾泛型委托EventHandler 让编译器自动约束事件参数类型写错类型在编译期就暴露而不是运行期才翻车。4. 避坑与排查事件和委托的五条实战踩坑记录4.1 触发事件时报“未将对象引用设置到对象的实例”现象代码写NotifyEvent(ss)运行时弹出NullReferenceException。原因事件字段是委托类型初始值是null。如果没有任何订阅者调用过触发时就是调用null变量必然抛异常。原笔记直接写a(ss)能跑通是因为构造函数中订阅了d方法但换个场景、订阅代码放错位置或被移除马上就崩。解决统一使用空条件运算符触发即NotifyEvent?.Invoke(ss)。这个写法一行解决判空问题后续所有新代码都用这个模式。另有一个隐藏细节使用局部变量复制再调用也能避免多线程下的竞态条件但窗体程序里更多用?.Invoke简单直接。4.2 另一个线程触发了事件窗体控件更新报“线程间操作无效”现象后台线程处理完数据后触发事件事件处理方法里更新label.Text运行时抛InvalidOperationException提示“线程间操作无效”。原因WinForms的UI控件只能在创建它的线程上更新。委托事件本身不负责线程切换后台线程触发事件时执行上下文还在后台线程直接更新控件就撞上了界面线程安全检查。解决事件处理方法里用this.Invoke((MethodInvoker)delegate { label.Text ...; });来切换回UI线程。更优雅的是用async/await配合Task.Run让await返回后自然回到UI上下文。注意一点事件触发处不要自己加线程切换那是处理方职责否则会泄漏线程模型到事件源。4.3 多次打开子窗体事件处理方法被重复执行现象父窗体打开子窗体后关闭再打开再关闭第三次打开时事件触发后RefreshListView被调用了三次。原因每次打开子窗体都会执行child.DataSaved RefreshListView而事件字段持有的是委托的多播列表。子窗体关闭后垃圾回收不会自动收回事件订阅旧实例的订阅链还在新实例又加了一次。解决在父窗体关闭子窗体时显式退订或者干脆在子窗体Load事件里订阅、在FormClosed里退订。对于单例子窗体每次打开前先child.DataSaved - RefreshListView再就能防重复。核心习惯是谁订阅谁退订订阅和退订配对出现。4.4 事件处理方法里抛异常后续订阅者不再执行现象事件上方两个订阅方法第一个抛出异常第二个没有被调用整个程序像卡了一下。原因多播委托是顺序执行的某个方法的异常会中止后续方法的执行。这和“广播通知”的直觉不符很多人以为事件应该隔离异常。解决在事件源类内部对订阅者的调用做统一包装——遍历委托调用列表逐个try/catch让一个订阅者失败不影响其他订阅者。另一个方案是委托返回bool每个处理方法返回是否成功但改动大不推荐。最实用的还是try/catch隔离把事件处理方法当成黑匣子谁出错谁自己处理。4.5 委托与事件签名不匹配编译期不报错但运行期触发失败现象声明委托public delegate void NotifyHandler(string s)后面改成public delegate void NotifyHandler(string s, int code)但事件声明处忘了改编译报错。原因事件声明依赖委托类型委托类型一变事件签名跟着变所有订阅和触发点都要对齐。手改很容易漏掉某一处。解决从一开始就用框架内置的EventHandlerEventHandler 不需要自定义委托就尽量不自定义。对大多数窗体通信场景EventHandlerT覆盖了所有需求而且编译器会在类型不匹配时给出明确提示。自定义委托只用在“返回值或参数形状与标准模式差距很大”的时候。下面把常见问题整理成一张对照表方便快速定位错误现象主要原因修复方向NullReferenceException事件无订阅者触发?.Invoke判空触发线程间操作无效后台线程更新UI处理方Invoke或await处理方法重复执行重复订阅未退订-与成对出现异常中断后续订阅者多播顺序执行无隔离遍历调用链try/catch编译报错签名不符委托类型不一致统一用EventHandler5. 进阶用法泛型事件参数与异常隔离的组合实践5.1 用EventHandler 替代自定义委托写事件处理代码时我一般会默认走EventHandlerT。这样事件参数有了强类型约束订阅方拿到的不仅是数据还有类型信息。比如做下载任务通知可以定义一个DownloadEventArgs携带文件名、进度百分比、是否成功三个字段事件签名保持EventHandler 后续加字段只改参数类不改事件声明。public class DownloadEventArgs : EventArgs { public string FileName { get; } public int ProgressPercent { get; } public bool Succeeded { get; } public DownloadEventArgs(string fileName, int percent, bool ok) { FileName fileName; ProgressPercent percent; Succeeded ok; } }好处是触发方和订阅方的编译期契约非常明确。原实例那种裸string参数在快速演示时够用但到了多人协作的项目里字段名取代魔法字符串能省很多传参错误。5.2 在触发处做参数快照避免上下文被外部篡改委托是引用类型事件参数对象同样在堆上共享。如果订阅方在事件处理方法中修改了传入对象的状态触发方后续代码可能感知到变化。常见做法是让事件参数类尽量只读——构造函数一次性赋值属性不带setter。上面DownloadEventArgs里属性只有getter就是这个考虑。另一个技巧是使用record类型自带值语义但会引入较新的语言特性按团队习惯取舍。5.3 事件触发上下文中的异常隔离习惯某个模拟项目X中日志订阅方法里抛了异常导致主业务方法中断排查了很久才发现是日志系统自身的问题。从此之后我在事件触发位置做两层防护触发处判空事件处理逻辑内try/catch。这是强制习惯。private void RaiseDataSaved(string fileName, long fileSize) { var handler DataSaved; // 局部变量防止多线程竞态 if (handler null) return; var args new DataSavedEventArgs(fileName, fileSize); var invocationList handler.GetInvocationList(); foreach (Delegate single in invocationList) { try { ((EventHandlerDataSavedEventArgs)single)(this, args); } catch (Exception ex) { Trace.WriteLine($事件处理方法异常{ex.Message}); } } }这段代码把多播委托里的每个订阅者单独取出逐个调用并包裹异常一个订阅者挂掉不影响其他订阅者。局部变量handler避免触发瞬间另一线程退订引起的委托链变化这是考虑多播委托不变性后的写法。参数说明GetInvocationList返回Delegate数组按订阅顺序排列强转成具体委托类型再调用。Trace.WriteLine只记录不抛出日志隔离在这层做掉。从那以后我每次写事件触发都强制走一遍“判空-快照-逐项try/catch”的流程已经很少遇到事件链上连环崩的情况。希望帮到你。本文还有配套的精品资源点击获取
