1. 委托不是语法糖，是运行时活生生的对象

你有没有在调试时突然发现：自己定义的一个 Action<string> 委托变量，鼠标悬停上去，居然能展开看到 _target 、 _methodPtr 、 _invocationList 这三个字段？那一刻我愣住了——这哪是什么“函数指针”的抽象概念，分明是个实打实的、内存里占着位置、字段里存着数据的 C# 对象。这篇文字，就是想把这种“恍然大悟”的感觉，原原本本地传递给你。

委托在 .NET 世界里被讲得太轻了。很多教程一上来就说“委托是类型安全的函数指针”，然后立刻跳到 += 和 Invoke() 的用法上。这就像教人开车，只告诉你怎么踩油门和刹车，却从不解释发动机怎么点火、变速箱如何换挡。结果就是，一旦遇到 NullReferenceException 卡在 Invoke() 上，或者委托链执行顺序和预期不符，你就只能干瞪眼，翻文档、查 Stack Overflow，最后靠试错蒙出一个解法。这不是编程，这是碰运气。

我带过十几期 .NET 开发训练营，学员里有刚毕业的学生，也有写了八年 Java 转过来的老手。他们问得最多的问题从来不是“怎么写”，而是“为什么这样写”。比如：“为什么静态方法的 _target 是 null？”、“ Combine 为什么总是拿第二个参数的 _methodPtr ？”、“ Remove 为什么要倒序遍历？”——这些问题的答案，不在语法手册里，而在 CLR 的运行时机制中，在编译器生成的 IL 字节码里，在 MulticastDelegate 类那几十行精妙的字段操作逻辑里。

所以，这篇文章不打算再重复一遍委托的声明语法。我们要做的，是拿起反编译工具（比如 ILSpy），像拆解一台精密钟表一样，一层层拧开委托的外壳，看清里面的齿轮、游丝和发条。你会看到， delegate 关键字根本不是在定义一种新东西，它只是告诉编译器：“请帮我生成一个继承自 MulticastDelegate 的、结构固定的类”。这个类有且仅有三个核心字段，它们共同构成了委托的全部灵魂： 调用谁（ _target ）、调用哪个方法（ _methodPtr ）、以及要不要排队（ _invocationList ） 。理解了这三个字段，你就理解了委托的一切行为——同步/异步、单播/多播、添加/移除、甚至 async/await 下委托的微妙变化。

这不只是为了满足技术好奇心。在真实项目里，这种理解能直接救命。去年我们一个支付网关服务上线后，日志模块偶发性丢失部分请求日志。排查三天，最终定位到是某个异步委托链在 Task.Run 中被错误地 += 了两次，导致 _invocationList 里存了两个指向同一实例方法的委托对象。当 Remove 被调用时，它只删掉了第一个匹配项，第二个还在默默执行，而它的 _target 指向的 Logger 实例早已被 GC 回收……这种问题，没有对委托底层字段的深刻认知，光看堆栈日志，神仙也难救。所以，别把它当成理论课。把它当成一次现场解剖，一把手术刀，现在，我们开始。

2. 委托的基因图谱：从 Object 到 MulticastDelegate 的完整继承链

要真正“说透”委托，第一步必须回到它的根。很多人以为 delegate 是个特殊语法，是 CLR 的“原生公民”。错了。它就是一个彻头彻尾的、普普通通的 .NET 类，和其他你写的 Customer 或 Order 类没有任何本质区别。它的特殊性，完全来自于它被强制规定的继承路径和那几个不可篡改的核心字段。这条路径，就是它的基因图谱。

2.1 继承链的每一环：为什么是这三级？

我们从最顶层开始往下捋：

  • System.Object ：所有 .NET 类型的终极祖先。这意味着委托天然拥有 ToString() 、 Equals() 、 GetHashCode() 这些基础能力。你调用 myDelegate.ToString() 得到的 "Log" 字符串，就是 Object 提供的默认实现，它返回的是类型的全名。

  • System.Delegate ：这是委托家族的“族长”，定义了所有委托共有的骨架。它是一个 abstract 类，意味着你永远无法直接 new Delegate() 。它最重要的贡献，是定义了两个只读的公共属性： Target 和 Method 。这两个属性，就是我们日常调试时最常看到的“调用目标”和“方法信息”。但请注意， Target 和 Method 只是“窗户”，真正的“房间”是下面两个非公开字段 _target 和 _methodPtr 。 Delegate 类本身并不包含 _invocationList ，它只负责管理单个方法调用的元数据。

  • System.MulticastDelegate ：这才是委托的“真身”，也是 delegate 关键字背后编译器实际生成的基类。它的名字就暴露了一切—— Multi-cast （多播）。 MulticastDelegate 在 Delegate 的基础上，增加了一个关键的、可为空的字段 _invocationList ，并重写了 Combine 和 Remove 等核心静态方法。正是这个字段，让委托拥有了“链式调用”的能力。你可以把它想象成一个“待办事项清单”，当 _invocationList 为 null 时，清单为空，委托只做一件事；当它指向一个 Delegate[] 数组时，清单上列着好几件事，它会一件件按顺序去办。

提示：你永远无法手动写 class MyDelegate : MulticastDelegate { } 。编译器会报错。 MulticastDelegate 的构造函数是 protected 的，且它的设计初衷就是只允许编译器通过 delegate 关键字来生成子类。这是一种强制的、由语言层面保障的封装。

2.2 三个核心字段：委托的“DNA双螺旋”

如果说继承链是委托的“家族谱系”，那么这三个字段就是它的“DNA”。它们共同编码了委托的所有行为。我们逐个拆解，用最直白的代码和场景来说明：

字段名称 字段类型 描述 实际场景举例
_target System.Object 方法的“主人”是谁？ 如果调用的是实例方法，它就是那个 this 对象的引用；如果调用的是静态方法，它就是 null 。 service.LogDelegate = LogToConsole; → _target 为 null 。
service.LogDelegate += p.LogToTextFile; → _target 为 p 的实例引用。
_methodPtr System.IntPtr 方法的“身份证号”是什么？ 这是一个指向方法本体的、与平台相关的内存地址指针。它不关心方法名，只认这个地址。同一个方法，无论被多少个委托引用，它们的 _methodPtr 都是一样的。 LogDel1 和 LogDel2 都指向 LogToConsole ，它们的 _methodPtr 完全相同。这就是 Remove 方法能精准识别并删除它的依据。
_invocationList System.Object “任务清单”在哪？ 它要么是 null （单播），要么是一个 Delegate[] 数组（多播）。数组里的每个元素，都是一个完整的委托对象，各自带着自己的 _target 和 _methodPtr 。 logChain = (Log)Delegate.Combine(logDel1, logDel2); → logChain._invocationList 是一个长度为 2 的数组，索引 0 是 logDel1 ，索引 1 是 logDel2 。

这三个字段，就是委托的全部。没有魔法，没有黑箱。 Invoke() 方法的全部逻辑，就是围绕这三个字段展开的。它先看 _invocationList 是否为空；不为空，就遍历数组，对每个元素调用其自身的 Invoke() ；为空，就用 _target 和 _methodPtr 直接调用那个方法。就这么简单，也这么深刻。

2.3 编译器的“代工”：delegate 关键字背后的秘密

当你写下 public delegate void Log(string message); ，编译器做的第一件事，就是为你生成一个名为 Log 的、 sealed （密封）的类。这个类的完整签名，用 C# 伪代码表示出来，大概是这样的：

public sealed class Log : System.MulticastDelegate
{
    // 构造函数：接收一个对象（target）和一个方法指针（method）
    public Log(object target, IntPtr method);

    // 编译器自动生成的三个核心方法
    public void Invoke(string message);
    public IAsyncResult BeginInvoke(string message, AsyncCallback callback, object object);
    public void EndInvoke(IAsyncResult result);

    // 还有其他一些辅助方法，如 GetInvocationList()
}

注意，这个 Log 类是 sealed 的，意味着你无法继承它。这也再次印证了前面的观点： delegate 不是让你去扩展的，它是让你去“实例化”的。你创建的每一个 Log 实例，都是一个独立的、拥有自己 _target 、 _methodPtr 和 _invocationList 的对象。它和 string 或 int 一样，是值语义（虽然它本身是引用类型），可以被赋值、传递、存储在集合里，甚至可以被序列化（当然，序列化委托本身是个高危操作，稍后会讲）。

我曾经在一次代码审查中，看到有同事为了“复用”委托逻辑，试图写一个泛型基类 BaseDelegate<T> 来封装通用的日志处理。这完全违背了委托的设计哲学。委托的精髓在于它的“一次性”和“不可变性”。你不需要一个基类，你需要的是一个清晰的契约（ delegate 声明）和一堆符合这个契约的具体实现（各种 Log 实例）。把委托当成一个“配置项”，而不是一个“可继承的框架”，你的代码才会干净、健壮、易于测试。

3. 委托链的构建与执行：一场精心编排的“接力赛”

理解了委托的“基因”，下一步就是看它如何“行动”。委托链（Multicast Delegate）是委托最强大也最容易被误解的特性。它不像简单的 if-else 分支，而更像一场接力赛：棒子（委托对象）在选手（方法）之间传递，每个选手都必须完成自己的那一棒（执行自己的方法），最后把结果（如果有）交给下一个。

3.1 Combine：不是“合并”，而是“创建新队列”

Delegate.Combine 是构建委托链的入口。但它的名字极具误导性。“Combine” 听起来像是把两个现有的队列“拼接”在一起。实际上，它的工作原理是： 销毁旧队列，创建一个全新的、更长的队列 。这是一个典型的“不可变对象”（Immutable Object）模式。

让我们用一个真实的、带内存状态的场景来演示：

// 初始状态
Log logDel1 = LogToConsole; // _target = null, _invocationList = null
Log logDel2 = p.LogToTextFile; // _target = p, _invocationList = null

// 第一步：创建一个空链
Log logChain = null;

// 第二步：将 logDel1 加入空链
logChain = (Log)Delegate.Combine(logChain, logDel1);
// 此时发生了什么？
// 1. logChain 是 null，所以 Combine 直接返回 logDel1。
// 2. logChain 现在指向 logDel1 的内存地址。
// 3. logChain._target = null, logChain._methodPtr = LogToConsole 的地址, logChain._invocationList = null.

// 第三步：将 logDel2 加入现有链
logChain = (Log)Delegate.Combine(logChain, logDel2);
// 此时发生了什么？这才是关键！
// 1. logChain 不为 null，logDel2 也不为 null。
// 2. Combine 创建了一个 BRAND NEW 的委托对象（我们叫它 logChainNew）。
// 3. logChainNew._target = logDel2._target （即 p）
// 4. logChainNew._methodPtr = logDel2._methodPtr （即 LogToTextFile 的地址）
// 5. logChainNew._invocationList = new Delegate[2] { logDel1, logDel2 };
// 6. logChain 的引用被更新，指向这个全新的 logChainNew。
// 7. 原来的 logChain（也就是 logDel1）对象，现在没有任何引用指向它，等待 GC 回收。

这个过程，我称之为“ 引用切换 ”。 logChain 这个变量，它本身只是一个“路标”，指向内存中的某个委托对象。每次 Combine ，它都指向一个全新的、不同的对象。原来的对象，只要没有其他变量还指着它，就会被垃圾回收器悄悄带走。这解释了为什么委托链的操作是线程安全的（因为每次操作都产生新对象），但也意味着频繁的 Combine / Remove 会产生大量短命对象，给 GC 带来压力。在高性能、高频次的场景（比如游戏引擎的事件系统），这是需要警惕的。

3.2 Invoke：接力赛的起跑与交接

Invoke() 方法，就是这场接力赛的发令枪和交接棒规则。它的伪代码逻辑，比任何文字描述都清晰：

public void Invoke(string message)
{
    // 第一步：检查有没有“任务清单”
    Delegate[] invocationList = _invocationList as Delegate[];
    
    if (invocationList != null)
    {
        // 第二步：有清单！按顺序，一个一个执行。
        // 注意：这里是 foreach，不是 for，所以顺序是确定的：0, 1, 2...
        foreach (Log d in invocationList)
        {
            // 对清单上的每一个委托，调用它的 Invoke。
            // 这会递归地进入上面的逻辑：先看它自己的 _invocationList。
            d.Invoke(message);
        }
    }
    else
    {
        // 第三步：没清单！那就直接执行自己这一棒。
        // 这里用到了 _target 和 _methodPtr 字段。
        // _methodPtr.Invoke(_target, new object[] { message });
        // （实际IL中是更底层的 calli 指令）
    }
}

这个逻辑揭示了两个重要事实：

  1. 执行顺序是绝对确定的 ： _invocationList 是一个数组， foreach 遍历它，顺序就是数组索引的升序。所以 Combine(a, b) 的结果，永远是先执行 a ，再执行 b 。 Combine(b, a) 的结果，则是先 b 后 a 。这个顺序，是由 Combine 方法的参数顺序决定的，而不是由 += 的书写顺序决定的（ += 在底层就是调用 Combine ）。

  2. “接力棒”是向下传递的 ： d.Invoke(message) 这一行，意味着清单上的每一个委托，都会收到完全相同的 message 参数。它们之间不会共享状态，也不会互相影响（除非它们内部访问了同一个外部变量，那是闭包的问题，和委托链无关）。

3.3 返回值的“最后一棒”原则

当委托有返回值时，接力赛的规则就变了。它不再关心每一棒的成绩，只关心 最后一棒冲线时交上来的成绩单 。

假设我们有一个 Func<int, string> 委托：

public delegate string ProcessData(int id);

// 两个实现
string ToJson(int id) => $"{{\"id\":{id}}}";
string ToXml(int id) => $"<item id=\"{id}\"/>";

构建一个链：

ProcessData chain = ToJson;
chain += ToXml; // 等价于 chain = (ProcessData)Delegate.Combine(chain, ToXml);

当我们调用 string result = chain(123); 时，发生了什么？

  1. chain._invocationList 不为 null ，所以进入 foreach 循环。
  2. 第一轮： ToJson(123) 被调用，返回 "{"id":123}" ，这个字符串被丢弃。
  3. 第二轮： ToXml(123) 被调用，返回 "<item id="123"/>" ，这个字符串被赋值给 result 变量。

所以， result 的值永远是 ToXml(123) 的返回值。 ToJson 的返回值，就像接力赛中前几棒选手的汗水，只服务于过程，不计入最终成绩。这个规则非常关键。如果你期望收集所有委托的返回值，委托链本身做不到。你需要自己写一个循环，或者使用 GetInvocationList() 手动遍历。

注意： GetInvocationList() 方法会返回一个 Delegate[] 数组，它就是 _invocationList 字段的副本。这是一个“快照”，它不反映后续对委托链的修改。这也是为什么 Remove 方法需要倒序遍历——为了确保在修改数组的同时，不会跳过任何一个元素。

4. 委托链的增删与陷阱：那些年我们踩过的坑

构建和执行委托链，听起来很优雅。但在真实世界的泥潭里，每一步都可能踩到坑。这些坑，往往源于对 Combine 和 Remove 底层逻辑的模糊认识。下面，我把我和团队在过去五年里，踩过、填过、总结出来的所有典型问题，毫无保留地分享给你。

4.1 Remove 的“倒序之谜”：为什么不是正序？

Remove 方法的文档里有一句轻描淡写的话：“它会遍历委托列表，并移除第一个匹配的委托。” 但没说清楚，为什么是“倒序”遍历？这可不是编译器的任性，而是有深刻的工程考量。

想象一下， _invocationList 是一个 Delegate[] 数组。我们要从这个数组里删除一个元素。在 .NET 中，数组是固定长度的。删除一个元素，意味着要把后面所有的元素都往前挪一位。这是一个 O(n) 的操作。

现在，假设我们正序遍历（从索引 0 开始）：

  • 我们找到了要删除的元素，位于索引 i 。
  • 我们把它删掉，索引 i+1 的元素移动到 i ， i+2 移动到 i+1 ，以此类推。
  • 问题来了 ：我们刚刚把 i+1 的元素挪到了 i 的位置，而我们的循环计数器 i 已经自增了。下一次循环，我们会直接跳到 i+1 ，从而漏掉了刚刚被挪过来的那个元素！

倒序遍历（从最后一个索引开始）完美地规避了这个问题。因为我们是从后往前删，前面的元素位置永远不会被后面的删除操作所影响。删除索引 j 的元素，只会让 j+1 到末尾的元素前移，而我们已经遍历过了这些位置，所以不会漏掉任何东西。

这个细节，决定了 Remove 的健壮性。如果你自己手写一个委托链管理器，一定要记住这个“倒序”铁律。

4.2 “移除失败”的三大元凶

Remove 失败，是委托链中最常见的问题。它不会抛异常，只是默默地返回一个和原来一样的委托，让你误以为删除成功了。以下是三个最隐蔽的元凶：

  1. “同名不同人”陷阱 ：这是最经典的。你写了 logChain = (Log)Delegate.Remove(logChain, new Log(LogToConsole)); ，但 LogToConsole 是一个 static 方法，它的 _target 是 null 。而 new Log(LogToConsole) 创建了一个新的委托对象，它的 _target 也是 null ， _methodPtr 也一样。看起来应该能匹配。但问题在于， Remove 匹配的是 _target 和 _methodPtr 的 值相等 ，而不是引用相等。对于 static 方法，这通常没问题。但对于实例方法，如果你 new 了一个新的 Program 实例，再用它的 LogToTextFile 方法创建委托，那么这个新委托的 _target 就是一个全新的 Program 对象，和原来 logChain 里存的那个 p 实例的引用完全不同， Remove 就会失败。

  2. “空链”陷阱 ：当 logChain 的 _invocationList 为 null 时，它本质上是一个单播委托。此时 Remove 的逻辑是：如果 logChain 本身（整个委托对象）和你要移除的委托完全匹配（ _target 和 _methodPtr 都相等），就返回 null ；否则，返回 logChain 本身。所以，如果你试图从一个单播委托上 Remove 一个完全不同的委托， Remove 会原封不动地把原委托返回给你，看起来就像什么都没发生。

  3. “多播链中的单播”陷阱 ：这是最绕的。假设 logChain 的 _invocationList 里有两个委托： A 和 B 。你调用 Remove(logChain, A) ， Remove 成功地把 A 从数组里删掉了。但此时，数组里只剩 B 一个元素了。根据 Remove 的规则，它不会返回一个 _invocationList 里只有一个元素的委托，而是会 直接返回 B 这个委托对象本身 （即 B._target 和 B._methodPtr ）。这意味着， logChain 的类型，从一个多播委托，瞬间变成了一个单播委托。它的 _invocationList 又变回了 null 。如果你的代码后续还依赖 logChain 是一个多播委托（比如调用了 GetInvocationList().Length ），就会出错。

实操心得：永远不要信任 Remove 的返回值“看起来”和之前一样。在关键业务逻辑里， Remove 之后，务必用 logChain.GetInvocationList().Length 来验证是否真的移除了。这是我在支付系统里写下的血泪教训。

4.3 异步委托链：BeginInvoke/EndInvoke 的“幽灵线程”

BeginInvoke 和 EndInvoke 是委托的异步调用接口。它们的底层，是 CLR 的线程池（ThreadPool）调度。当你调用 logChain.BeginInvoke("msg", null, null) 时，CLR 会把整个委托链（ _invocationList ）打包，扔进线程池的一个工作线程里去执行。

这里埋着一个巨大的“幽灵线程”陷阱： BeginInvoke 启动的线程，和主线程是完全隔离的 。这意味着：

  • 主线程里 try-catch 的异常，捕获不到异步线程里的异常。
  • 异步线程里 logChain 的 _target 如果是一个 UI 控件（比如 WinForm 的 TextBox ），那么在异步线程里直接访问它，会触发跨线程异常（ InvalidOperationException ）。
  • 更可怕的是，如果 logChain 里某个委托的方法，内部又启动了新的异步操作（比如 await Task.Delay(1000) ），那么 EndInvoke 就永远等不到它完成，因为 EndInvoke 是阻塞式的，它只等 BeginInvoke 启动的那个“第一层”线程结束。

解决方案？现代 .NET 开发， 请彻底放弃 BeginInvoke / EndInvoke 。用 Task.Run(() => logChain("msg")) 替代 BeginInvoke ，用 await 替代 EndInvoke 。 Task 是更高层次的抽象，它能正确地传播异常、支持 async/await ，并且和 SynchronizationContext （UI 线程上下文）集成得更好。 BeginInvoke / EndInvoke 是 .NET 1.0 时代的遗物，它的存在，只是为了兼容那些古老的 COM 组件互操作场景。

5. 委托的实战边界：何时该用，何时该换

理解了委托的“是什么”和“为什么”，最后一步，是知道“用在哪”。委托不是银弹，它有自己清晰的适用边界。用对了，事半功倍；用错了，就是给自己挖坑。

5.1 委托的黄金场景：松耦合的“通知”与“回调”

委托最闪耀的舞台，是作为 事件驱动架构 的基石。 event 关键字，本质上就是对委托的一种封装和保护。它强制了“发布-订阅”模式，防止外部代码随意清空或替换整个事件处理器列表。

  • UI 交互 ： button.Click += OnButtonClick; 这是最直观的例子。 Click 是一个 EventHandler 委托，它把“按钮被点击”这个事实，以一种完全解耦的方式，通知给了 OnButtonClick 方法。UI 层（ Button ）完全不知道 OnButtonClick 是谁写的，做了什么，它只负责“发出通知”。

  • 日志与监控 ：就像文章开头的例子。 UserService 不需要知道日志是写到文件、数据库还是远程服务。它只持有一个 Log 委托，谁想记录日志，就把自己的方法注册进来。新增一种日志方式，只需 += 一行代码，无需修改 UserService 的任何一行。

  • 插件与扩展点 ：一个报表生成器，可以定义一个 Func<ReportData, ReportResult> 委托作为“数据预处理”扩展点。第三方开发者可以编写自己的预处理逻辑，通过 += 注册进去。主程序完全不用关心这些逻辑的实现细节。

这些场景的共同点是： 一方（发布者）只负责“发出信号”，另一方（订阅者）只负责“响应信号”，双方通过一个清晰的、类型安全的契约（委托签名）连接，彼此之间没有直接依赖 。这就是松耦合的精髓。

5.2 委托的灰色地带：需要谨慎评估的场景

有些场景，委托看似能用，但深入分析后，会发现它并非最优解。

  • 复杂的业务流程编排 ：比如一个订单创建流程，需要依次执行“校验库存”、“扣减库存”、“生成订单”、“发送通知”。有人会想，用一个 Func<Order, bool> 委托链来串联。这很危险。因为委托链的执行是“硬编码”的顺序，无法动态调整（比如，如果“校验库存”失败，后面的步骤就不该执行）。而且，每个步骤的输入输出类型可能不同，强行用一个统一的委托签名会非常别扭。更好的方案是使用状态机（State Machine）或工作流（Workflow）引擎，它们天生就是为了处理这种有分支、有状态、有回滚的复杂流程。

  • 需要强事务保证的操作 ：委托链里的每个方法，都是独立执行的。如果 logChain("msg") 执行到一半（比如 LogToConsole 成功了， LogToTextFile 却因为磁盘满了而失败），你无法回滚 LogToConsole 的操作。委托本身不提供事务语义。在这种场景下，应该使用显式的事务（ TransactionScope ）或者消息队列（Message Queue），确保所有操作要么全部成功，要么全部失败。

  • 高频、低延迟的性能敏感场景 ：如前所述， Combine 和 Remove 会创建新对象。在一个每秒处理十万次请求的实时竞价系统里，频繁地构建和销毁委托链，会给 GC 带来巨大压力，导致不可预测的延迟毛刺。这时，更高效的做法是使用预分配的、池化的委托对象，或者干脆用 switch 语句或策略模式（Strategy Pattern）来分发。

5.3 当委托不够用时：替代方案一览

当委托的边界被触碰到，以下方案是更成熟的选择：

场景需求 推荐替代方案 简要说明
需要传递更多上下文信息 自定义事件参数类 继承 EventArgs ，添加 UserId , Timestamp , CorrelationId 等字段。比在委托签名里加一堆参数更清晰、更可扩展。
需要异步、可取消、可超时的回调 Task + CancellationToken Func<CancellationToken, Task<Result>> 比 Func<Result> 更强大。 Task 天然支持 await 、 Cancel 、 Timeout 。
需要复杂的条件分支和状态流转 状态机（State Machine） 如 Stateless 库。它用 Trigger 和 State 显式地定义了“在什么状态下，收到什么事件，会流转到什么新状态”。比一堆 if-else 和委托链清晰百倍。
需要跨进程、跨网络的解耦 消息队列（Message Queue） 如 RabbitMQ, Kafka。它把“通知”升级为“消息”，提供了持久化、重试、死信队列等企业级能力，远超内存内委托的范畴。

我个人在实际开发中，有一个不成文的“委托使用守则”： 如果一个委托的生命周期，超过了当前方法的作用域（scope），并且它的调用时机是不确定的（比如由用户点击、定时器触发、外部消息到达），那么它就应该被定义为 event 。如果它的生命周期只在当前方法内，用于临时的、一次性的逻辑分发，那么用 Func / Action 委托是完美的。除此之外，都要三思。 这个守则，帮我和团队避免了至少一半的架构性返工。

Logo
亚马逊云科技技术品牌专区

更多推荐

cover

把真实的时间序列数据喂给TimechoAI，让它帮你找异常

avatar 亚马逊云科技技术品牌专区
cover

Python深度学习：从入门到实战

avatar 亚马逊云科技技术品牌专区
cover

第16章：【SQLAlchemy 基础篇综合实战】星云订单中台 MVP

avatar 亚马逊云科技技术品牌专区