中介者模式把对象之间的直接相互调用换成通过一个中介者来协调，从而降低耦合、集中通信逻辑并更容易扩展。它适合处理多对象复杂交互、协议频繁变动或需要集中控制的系统，但要警惕把太多责任堆到中介者上导致难以维护或性能瓶颈。
先说个简单的类比（费曼式入门）
想象一间办公室里有好几个人，大家互相发邮件、打电话、传纸条。如果每个人都直接联系，关系网会变得混乱。*中介者*就像办公室前台：所有人先把信息交给前台，前台再负责通知目标。这样每个人只需要关心和前台打交道，协作变得清爽很多。
中介者模式是什么（核心概念）
中介者模式（Mediator Pattern）是一种行为型设计模式，定义一个中介者对象来封装一系列对象之间的交互。对象不再直接相互引用，而是通过中介者进行通信。这样可以减少类之间的耦合，让交互逻辑集中在一个地方。
要点速览
- 职责分离：把对象间的通信逻辑从各对象中抽离出来。
- 集中控制：中介者负责协调和管理交互流程。
- 低耦合：对象只依赖中介者接口，便于替换和测试。
什么时候该用中介者模式
这是个“什么时候用”的问题：我会在这些场景优先考虑中介者模式：
- 多个对象之间的交互非常复杂，任意两者都可能耦合。
- 对象之间的交互规则会频繁改变，需要集中修改点。
- 想要将通信协议、路由或仲裁逻辑抽象出来，便于测试和监控。
- 需要在运行时动态改变对象间的交互或添加新的参与者。
不适合的场景
- 交互非常简单，加入中介只会增加不必要的复杂度。
- 如果中介者变得过大、承担过多责任，会成为反模式（上帝对象）。
- 性能极端敏感的场景（单一中介可能成为瓶颈或单点故障）。
常见变体与实现方式
中介者可以以多种形态出现，不同实现适用于不同场景：
- 集中式中介者（Centralized Mediator）：一个单点中介者，负责所有路由和决策。实现简单，但需注意扩展与性能。
- 分布式中介者/子中介器（Hierarchical Mediator）：把中介器按模块分层，避免单点过大，便于拆分责任。
- 消息总线/事件总线（Event Bus）：事件发布/订阅模型，松耦合但隐含流向不如直接调用可控。
- 命令分发器（Command Dispatcher）：把动作封装为命令，通过中介分发到处理者，便于审计与回放。
简单代码示例（思想胜过语言）
下面用伪代码示例说明基本结构，重点在职责分离：
// 中介者接口
interface Mediator {
notify(sender, event);
}
// 具体中介者
class ConcreteMediator implements Mediator {
colleagues = [];
notify(sender, event) {
// 根据事件决定如何通知其他参与者
for (c in colleagues) if (c != sender) c.receive(event);
}
}
// 参与者
class Colleague {
mediator;
send(event) { mediator.notify(this, event); }
receive(event) { /* 处理 */ }
}
上面结构很简单：参与者知道中介者，中介者知道参与者。变化点都在中介者里，不在参与者里。
与其他模式的比较（便于理解）
| 模式 | 和中介者的区别/联系 |
| 观察者（Observer） | 观察者用于一对多发布订阅，中介者用于多对象规则的集中管理；事件总线是观察者的变体，与中介者重叠但更松耦合。 |
| 门面（Facade） | 门面提供简化接口以隐藏子系统复杂性，中介者负责协调对象之间交互，关注点不同但都减少外部复杂度。 |
| 命令（Command） | 命令封装请求为对象，中介者可作为命令的调度者，两者常结合使用以支持撤销、审计等。 |
真实世界的例子（便于联想）
- 聊天房间：每个用户不直接向其他用户发送消息，而是把消息送到聊天室服务，聊天室负责广播或转发。
- 航管系统：飞机不直接协调彼此，而是通过空中交通管制中心分配航路和着陆顺序。
- GUI 对话框：对话框中多个控件的交互（启用/禁用、同步值）常由一个中介者类来协调。
优点与缺点，别只看优点
优点
- 减少类之间的耦合，改动影响范围小。
- 集中管理交互逻辑，便于观察、测试与修改。
- 便于添加新参与者或改变协议而不修改现有参与者。
缺点与风险
- 中介者膨胀：如果把所有逻辑都放到中介者，中介会变成难以维护的“上帝对象”。
- 性能瓶颈：集中处理可能成为单点性能或延迟瓶颈。
- 隐式流：在事件驱动的实现里，消息流向不如显式调用直观，可能增加调试难度。
实践建议：如何设计一个健壮的中介者
下面是一些可直接落地的经验：
- 分层中介：按业务边界拆分中介器，避免一个类承担所有职责。
- 接口明确：中介者暴露清晰的接口，参与者只依赖接口而非实现。
- 职责委托：当中介者逻辑复杂时，把策略或规则提取为独立策略对象或规则引擎。
- 监控与限流：为中介者添加监控、性能指标与必要的限流，防止被突发流量拖垮。
- 可观测性：记录路由决策、消息元数据，便于回溯和故障定位。
- 测试优先：通过模拟中介器接口或注入测试中介，单元测试参与者与集成测试中介交互。
常见实现细节和优化手段
事件驱动与同步调用的选择
事件驱动（异步）能提高吞吐、解耦时间依赖，但增加不确定性（顺序、重试、丢失）。同步调用更容易理解和调试，但可能阻塞。按业务需求混合使用是常见做法。
拆分策略
- 按模块拆分中介器（业务边界）；
- 将路由、鉴权、审计拆成子责任，用组合而非单一类；
- 使用策略模式把不同决策逻辑抽象出来，运行时注入。
性能相关
- 缓存常用路由或决策结果；
- 异步处理非关键路径消息；
- 负载均衡多个中介实例并保持状态同步或采用无状态中介。
演进路径：从点对点到中介者，再到分布式总线
很多系统的演进路径都是：
- 早期：点对点调用，耦合高但开发速度快；
- 中期：引入中介者或服务层，抽离复杂交互；
- 成熟：拆分中介者、采用消息总线、事件溯源或CQRS，支持更高并发与灵活性。
用例：把一个混乱的通知系统改为中介者
举个更具体的例子：一个电商系统里库存、支付、发货、推荐模块各自通知对方，变化一多事务就变得复杂。把通知逻辑抽到“协同中介器”：
- 中介器接收事件（下单、支付成功、退货），并按规则触发对应模块。
- 中介器做幂等、重试和事务边界控制，参与者只关心自身业务。
- 如果出问题，可以在中介器层面日志回放，便于定位。
测试与运维要点（别忘了它们）
- 单元测试：对参与者使用模拟（mock）中介器；对中介器测试路由和规则。
- 集成测试：模拟真实的消息流，验证端到端行为。
- 负载测试：评估中介者在峰值下的响应与队列积压。
- 可回放日志：记录事件以便回放、回溯和灾备恢复。
典型反模式与如何避免
- 上帝中介：中介者承担业务逻辑而非协调。避免方法：把业务逻辑提取到服务层或策略对象。
- 隐式依赖：过多隐式事件会让行为难以追踪。避免方法：文档化事件契约，使用契约测试（contract testing）。
- 单点故障：没有冗余的单中介部署会导致整体可用性下降。避免方法：水平扩展中介实例、采用无状态或状态同步方案。
小结之外的思路（边想边写的提示）
对，要记住，设计模式不是万能钥匙。中介者能让复杂交互更可控，但它也会把复杂性从广泛分布的各处集中起来。通常我会先画出参与者之间的关系网络，判断是不是“交互复杂”这回事；如果确实复杂，才考虑分步引入中介者，同时设计好监控、限流与责任拆分。
如果你现在面临具体问题，可以把参与方列表、典型事件流程和性能目标发过来，我们可以一起把“中介者”拆成可交付的小步实现，别一次性把所有东西都扔进去。