中介者模式的核心作用是集中管理交互逻辑而非单纯解耦；它将散落的交互规则收拢至Mediator类，使耦合由网状变为星型，并需按业务场景划分职责、使用泛型保证类型安全、依赖抽象视图接口而非具体控件、结合事件总线处理跨模块通信，且须合理管理生命周期。
中介者模式的核心作用不是解耦，而是集中管理交互逻辑
中介者模式在 C# 中真正解决的不是“对象间有没有耦合”，而是“把原本散落在多个类中的交互规则，收拢到一个 Mediator 类里”。直接让两个类互相引用（比如 A 持有 B，B 持有 A）是强耦合；但若改成两者都只依赖抽象 IMediator，交互逻辑全由中介者调度，耦合就从“网状”变成了“星型”——这是可维护性的关键跃迁。
常见错误是把中介者写成空接口 + 一堆 if-else 分发，结果中介者自己变成上帝类。正确做法是：按业务场景划分职责，例如 UI 控件联动用 UIMediator，领域事件协调用 DomainMediator，不混在一起。
用泛型抽象中介者避免运行时类型转换
硬编码 object 参数或用 dynamic 会让中介者失去编译期检查，也难以重构。推荐用泛型约束定义消息契约：
public interface IMediatorwhere TRequest : IRequest { TResponse Send(TRequest request); } public interface IRequest
{ } public class LoginRequest : IRequest
{ public string Username { get; set; } }
这样既保留类型安全，又避免为每种交互写独立方法（如 HandleLogin()、HandleLogout()），后续加新请求只需新增实现类，不改中介者本身。
警惕“伪中介者”：别让中介者直接操作 UI 控件实例
在 WinForms 或 WPF 中，常见反模式是中介者直接持有 Button、TextBox 等控件引用。这会导致：
- 单元测试无法隔离（要 mock 控件就得引入整个 UI 栈）
- 中介者与具体 UI 框架绑定，换 Blazor 就得重写
- 生命周期错乱（控件被 dispose 后中介者还试图调用）
正确做法是让 UI 层暴露行为契约，例如：
public interface ILoginView
{
event Action OnLoginRequested;
void ShowError(string message);
void NavigateToHome();
}
// 中介者只依赖这个接口，不碰任何 System.Windows.Forms 控件
public class LoginMediator
{
private readonly ILoginView _view;
private readonly IAuthService _auth;
public LoginMediator(ILoginView view, IAuthService auth) => (_view, _auth) = (view, auth);
public void Initialize()
{
_view.OnLoginRequested += async username =>
{
var result = await _auth.LoginAsync(username);
if (result.Success) _view.NavigateToHome();
else _view.ShowError(result.Message);
};
}}
中介者 + 事件总线更适合跨模块通信
当对象属于不同模块（如订单模块、库存模块、通知模块），且不共享上下文时，硬塞进一个中介者反而增加依赖。此时应组合使用：
- 模块内用轻量中介者协调紧密协作组件（如订单创建页的表单、校验、提交按钮）
- 模块间用事件总线（如
IEventBus.Publish() ）解耦
- 中介者可以订阅事件（例如监听
OrderCreatedEvent 后触发本地 UI 更新），但不负责转发或转换事件
这种分层让变更影响范围清晰：改订单流程只动 OrderMediator，加短信通知只需新增事件处理器，不动原有中介逻辑。
最易被忽略的是中介者的生命周期管理——它不该是 static 单例，也不该和 UI 控件同生共死。通常按 Use Case（如一次登录流程）或作用域（如某个 TabPage）创建，用 DI 容器控制其存活期。否则容易引发内存泄漏或状态污染。
