在C#中，委托是一种类型安全的函数指针，它把方法及其调用目标封装为一个对象。与单纯的函数指针不同，委托可以持有多个方法，这种能力称为多播委托。实现多播的关键就是+=和-=这两个运算符。它们不是数值意义上的加减法，而是对委托内部调用列表的增删操作。理解这两个运算符，需要先弄清楚委托的不可变特性以及内部调用列表如何组织。
很多开发者第一次接触事件订阅时，会下意识地认为+=就是向一个集合里添加一个方法，-=就是从集合里删除一个方法。这种直觉方向是对的，但如果停留在集合操作的层面，就会忽略委托内部不可变对象设计带来的一系列影响。例如为什么多次订阅同一个方法后，一次-=只移除最后一次订阅？为什么多播委托有多个方法时，调用结果只保留最后一个返回值？这些问题的答案都藏在委托的底层实现中。
一、委托与多播委托的基本模型
C#中的委托类型本质上都继承自System.MulticastDelegate，而MulticastDelegate又继承自System.Delegate。一个委托实例内部可以持有一个调用列表，这个列表由多个Delegate对象组成。当委托只绑定一个方法时，内部结构相对简单，可能直接保存方法指针和调用目标；一旦使用+=添加第二个方法，运行时就会创建一个内部数组来维护完整的调用列表。
这个内部数组可以通过GetInvocationList()方法访问。它返回一个Delegate[]数组，数组中的每一项都代表一个单独的方法绑定。需要注意的是，返回的是数组副本，修改这个数组不会影响原委托。多播委托在调用时会按照数组中的顺序依次执行每一个方法。这个顺序就是方法通过+=被添加的顺序。
多播委托的不可变特性意味着任何一次
+=或-=操作都不会修改原来的委托对象，而是生成一个新的委托实例。原来的委托仍然保持自己的调用列表不变，这也符合.NET框架中字符串、委托等不可变类型的设计惯例。
理解这个基本模型之后，就能解释很多表面看起来奇怪的行为。比如有一个委托变量handler，执行handler += A之后，如果另一个变量也引用了原来的handler，那么原变量的调用列表不会受到任何影响。这种设计让委托在多线程环境下更安全，因为已经发布出去的委托实例不会被意外修改。
二、+=和-=在编译器层面做了什么
在C#代码中写handler += A，编译器并不会真的生成一个加法指令。对于普通的委托字段，它会被展开为类似下面的形式：
handler = (Action)Delegate.Combine(handler, new Action(A));
Delegate.Combine接收两个委托对象，返回一个新的委托实例。如果左侧委托为null，它会直接返回右侧新创建的委托；如果两个都不为null，它会创建一个新的多播委托，把两个调用列表合并起来。合并过程中会分配新的内部数组并复制原有方法引用，因此原委托保持不变。
同样地，handler -= A会展开为调用Delegate.Remove。它的逻辑是：从左侧委托的调用列表中查找与右侧方法匹配的项，并移除最后出现的一个匹配项。所谓匹配，对于实例方法来说要同时比较方法指针和调用目标对象；对于静态方法则只比较方法指针。如果调用列表中包含多个相同的订阅，Remove只会移除最后一个。如果移除之后调用列表为空，Remove返回null。
下面的代码展示了重复订阅时-=的行为：
using System;
class Program
{
static void Main()
{
Action handler = null;
handler += ShowMessage;
handler += ShowMessage;
Console.WriteLine(handler.GetInvocationList().Length); // 输出 2
handler -= ShowMessage;
Console.WriteLine(handler.GetInvocationList().Length); // 输出 1
}
static void ShowMessage()
{
Console.WriteLine("called");
}
}
可以看到，虽然方法ShowMessage被订阅了两次，执行一次-=之后还剩余一个订阅。这是Delegate.Remove从调用列表末尾开始查找的结果。如果希望一次性移除所有同名订阅，需要自己基于GetInvocationList()做过滤，或者避免重复订阅同一个方法。
对于事件来说，编译器会为事件生成私有的委托字段，以及add和remove两个访问器。外部代码对事件使用+=和-=时，实际调用的是这两个访问器，而不是直接操作字段。默认的add访问器内部使用Delegate.Combine，并通过Interlocked.CompareExchange保证线程安全。这也是使用事件而不是公共委托字段的重要原因之一。
三、返回值与异常：多播调用中的隐藏规则
多播委托的调用过程是按顺序同步执行调用列表中的每一个方法。如果委托有返回值，最终返回给调用者的只是最后一个方法的返回值，前面所有方法的返回值都会被丢弃。这一点在实际开发中很容易被忽略，尤其是把多播委托当作结果聚合器使用时，可能会得到与预期完全不同的结果。
using System;
class Program
{
static void Main()
{
Func<int> func = null;
func += () => 1;
func += () => 2;
func += () => 3;
int result = func();
Console.WriteLine(result); // 输出 3
}
}
上面的示例中，虽然三个方法分别返回了1、2和3，但最终result的值是3。如果业务上需要收集所有返回值，就必须通过GetInvocationList()手动遍历每一个子委托，并分别调用、分别保存结果。多播委托的设计目标并不是为了聚合返回值，而是为了广播通知，所以返回值规则更偏向于“最后一次调用覆盖前面的结果”。
异常处理是另一个需要特别小心的点。多播委托在调用某个方法时如果抛出异常，异常会立即向上传播，调用列表中排在该方法之后的其他方法都不会再执行。例如一个事件有三个订阅者，第二个订阅者抛异常，第三个订阅者的处理逻辑就会被跳过。如果希望隔离每个订阅者的异常，不让单个订阅者影响整条调用链，就需要手动遍历调用列表，并用try/catch包裹每一次调用。
using System;
class Program
{
static void Main()
{
Action handler = null;
handler += () => Console.WriteLine("first");
handler += () => throw new InvalidOperationException("second failed");
handler += () => Console.WriteLine("third");
foreach (Action single in handler.GetInvocationList())
{
try
{
single();
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
}
}
}
这个例子中，第三个订阅方法在手动遍历的模式下仍然会执行，因为每次调用都被独立的try/catch保护。这也是很多事件聚合器或消息总线内部采用的模式。它牺牲了一点代码简洁性，换来了调用链的稳定性和可诊断性。
四、事件中的+=/-=与内存泄漏
事件是委托的一种封装，本质上仍然是发布者持有订阅者的方法引用。一旦订阅者通过+=订阅了发布者的事件，发布者就会持有一个指向订阅者对象的委托引用。只要发布者对象仍然存活，订阅者对象即使已经不再被业务代码使用，也无法被垃圾回收器回收。这就是经典的事件订阅内存泄漏问题。
典型场景是：一个长生命周期的对象作为事件发布者，一个短生命周期的对象作为订阅者。短生命周期对象在创建时订阅事件，但在销毁时忘记使用-=取消订阅。结果发布者持续持有短生命周期对象的引用，导致该对象及它持有的所有资源都无法释放。时间一长，内存占用不断上升。
using System;
public class Publisher
{
public event EventHandler Started;
public void OnStarted()
{
Started?.Invoke(this, EventArgs.Empty);
}
}
public class Subscriber : IDisposable
{
private readonly Publisher _publisher;
public Subscriber(Publisher publisher)
{
_publisher = publisher;
_publisher.Started += HandleStarted;
}
private void HandleStarted(object sender, EventArgs e)
{
Console.WriteLine("handled");
}
public void Dispose()
{
_publisher.Started -= HandleStarted;
}
}
在这个例子中，Subscriber实现了IDisposable接口，在Dispose方法中通过-=主动取消订阅。这是最直接的修复方式。但在复杂的对象图中，确定在哪个时机取消订阅并不总是容易。因此还需要考虑其他方案，比如使用弱事件模式。
.NET中提供了WeakEventManager类来帮助实现弱事件。它允许发布者持有订阅者的弱引用，这样即使订阅者没有主动取消订阅，也不会影响垃圾回收。但弱事件模式会带来一些性能开销和代码复杂度，所以在大多数业务场景下，优先保证生命周期管理清晰、及时执行-=，仍然是更实用的做法。
另外还要注意，如果订阅者订阅的是一个静态事件，或者订阅者本身是一个静态对象，那么内存泄漏的风险会更加隐蔽。因为静态成员的生命周期通常与整个应用程序一样长，任何被静态事件持有的订阅者都很难被回收。因此对于静态事件，更需要严格控制订阅和取消订阅的配对关系。
总结来看，+=和-=虽然写起来简单，但它们连接的是一套完整的多播委托机制。理解不可变调用列表、返回值覆盖规则、异常传播行为以及事件订阅的生命周期影响，可以帮助开发者写出更健壮、更易维护的C#代码。委托的强大之处不在于运算符本身，而在于它背后清晰且可预测的组合模型。