多播委托是C#委托的默认行为，用+合并同类型委托即形成链式调用；执行严格按添加顺序，异常中断后续调用，移除依赖引用相等性，返回值仅取最后一个方法结果。
多播委托不是“高级技巧”，而是 C# 委托的默认行为——只要用 + 合并同类型委托，就自动形成链式调用；但它的执行逻辑、异常传播和移除机制极易被误用。
多播委托的创建与调用顺序
用 + 运算符合并两个或多个同签名委托时，C# 会生成一个 MulticastDelegate 实例，内部维护一个调用列表（GetInvocationList() 可查看）。调用时严格按添加顺序逐个执行：
-
hiDel + byeDel→ 先调Hello，再调Goodbye - 顺序由
+的左操作数决定：a + b + c等价于(a + b) + c，不是随机或逆序 - 若中间某个方法抛出未捕获异常，后续方法**不会执行**（无自动跳过）
示例中 multiDel("C") 输出两行，证明链式触发成立；但若 Hello 内 throw Exception，则 Goodbye 永远不会被调到。
从多播委托中安全移除方法
用 - 运算符移除组件委托时，C# 匹配的是**引用相等性**，不是方法名或签名：
-
multiDel - hiDel成功，因为hiDel是原始引用 -
multiDel - new CustomCallback(Hello)失败，新构造的委托对象 ≠ 原始hiDel - 移除后若链为空，结果为
null，直接调用会抛NullReferenceException
务必检查结果是否为 null，尤其在动态增删场景下。例如：var newDel = multiDel - hiDel; if (newDel != null) newDel("D");
多播委托的返回值与异常处理
多播委托的返回值只取**最后一个调用方法的返回值**，前面所有返回值被丢弃；异常则遵循“一崩全停”原则：
- 声明
Func<int>多播委托，即使前 3 个方法都返回42，最终结果也只是第 4 个方法的返回值 - 任一环节抛异常（如
InvalidOperationException），整个调用中断，且异常原样向上抛出 - 没有内置的“继续执行下一个”的容错模式，需手动遍历
GetInvocationList()并 try/catch 每一项
这意味着：依赖返回值聚合或需要稳定执行全部监听器的场景（如事件通知），不应直接依赖多播委托原生调用，而应显式循环处理。
为什么 Action<T> 和自定义委托都能多播，但要注意兼容性
多播能力不依赖委托声明方式，而取决于类型一致性和 .NET 的 MulticastDelegate 基类继承关系：
-
Action<string>、Func<int, string>、自定义delegate void LogHandler(string)都天然支持+/- - 但
Action<string>和LogHandler即使签名相同，也不能互相合并——类型不同 - 泛型参数必须完全一致：
Action<object>和Action<string>不兼容，编译报错
实际项目中混用命名委托和泛型委托很常见，合并前务必确认 typeof(委托A) == typeof(委托B)，否则编译不过，而不是运行时报错。
多播委托表面简单，但它的调用不可中断、返回值不可聚合、移除依赖引用相等性——这些都不是设计缺陷，而是明确的契约。用错的地方，往往不是语法写错了，而是没意识到它根本不是“自动重试队列”或“结果收集器”。
