先别急着翻 GoF 目录。我说一个你天天在用、但从没意识到它是设计模式的东西：消息队列。

不是比喻。消息队列就是中介者模式的分布式实现。Producer 和 Consumer 不直接通信。所有消息经过 Broker 中转——这就是中介者模式的灵魂：用一个中介对象封装一组对象的交互方式，让它们不直接引用彼此。怎么说呢，

一个没有中介者的聊天室

假设你写过一个简单的群聊功能。最开始你可能这么写：

public class User {
private String name;private List contacts;// 直接持有其他使用者引用
public void send {
for {
u.receive;}
}
}

功能没问题。现在需求来了的观点是，

• 有人退群。需要通知所有人刷新列表，
• 有人被禁言，只发消息给管理员。
• 有人发敏感词，需要先过滤再决定是否投递。

上面的代码每加一个需求就要改 User 类——消息路由、过滤、黑名单全塞在一起。三个月后 User.send 变成了数十行的 if‑else 地狱。更糟的是User 之间互相持有引用。退群时要遍历所有 User 删引用，漏一个就是内存泄漏。

痛点：代码膨胀、维护成本爆炸、内存泄漏隐患、业务规则改动导致全局回归。

中介者模式怎么解决？把通信逻辑抽出来放进一个独立的 ChatRoom 类。

public class ChatRoom {
private Map users = new HashMap<>;public void register {
users.put,user);}
public void send {
User recipient = users.get;if ) {
recipient.receive;}
}
public void broadcast {
for ) {
if .equals &&!u.isMuted) {
u.receive;}
}
}
}
public class User {
private String name;private ChatRoom room;// 只持有中介者引用
public void sendTo {
room.send;不过，}
public void sendAll {
room.broadcast;}
}

User 从互相引用的网状结构变成只依赖 ChatRoom 的星型结构。加禁言功能只改 ChatRoomUser 一行不动。这就是中介者模式的主要价值：把 M×N 的交互复杂度降为 M+N。

跟观察者模式的区别——很多人搞混

观察者: Subject 不知道 Observer 是谁，只管“有事件发生了你们自己看着办”。通信是单向广播，怎么说呢，

中介者: 通信双方都对 Mediator 发指令。Mediator 决定怎么路由、怎么协调。通信是多向且需要协调的，

聊天室里A 发消息给 B，B 的回复可能要通知 C。这个过程中 ChatRoom 做决策。不过，这就是中介者，不是观察者。

Pain point: 把观察者当中介者会导致事件无限传播、难以追踪的副作用。

消息队列就是中介者模式的工业级实现

回头看消息队列的架构：

Producer A ──→ ──→ Consumer X
Producer B ──→ ──→ Consumer Y
Producer C ──→ ──→ Consumer Z

 居中协调，生产者和使用者彼此不知道对方的存在。这正是标准的 Mediator。按理说，

Pain point: 如果没有 Broker。你需要在每个 Producer 与每个 Consumer 之间建立直连，连接数瞬间爆炸，运维成本成倍增长。

T​ype 示例：RocketMQ 的 Tag 过滤、顺序消息、事务消息——这些都是 Mediator 在“封装交互”。没有 Broker，你得在每个 Producer 与每个 Consumer 手动实现过滤、事务控制等逻辑，代码重复且易出错。

I 曾在一个订单程序里看到这种惨状。早期架构里订单服务直接调用库存、支付、物流三个服务——四个服务六对调用关系。后来加了优惠券和积分服务，变成十五对调用关系。每改一个服务接口，都要改四五个调用方。

Pain point: 接口变更导致跨服务连锁反应，线上故障率飙升。

上了消息队列后订单服务只管往 Topic 发消息；库存、支付、物流各自订阅感兴趣的 Topic。订单服务不需要知道使用者是谁，也不关心使用者有多少实例。

S​pring 里到处都是中介者的影子

S​pring 的 @ApplicationEvent/ApllicationEventPublisher 机制本质上就是 Mediator：

@Component
public class OrderMediator {
@Autowired
private ApplicationEventPublisher publisher;public void placeOrder {
// 业务逻辑...
publisher.publishEvent);// ApplicationContext 作为中介者，把事件路由给所有监听器
}
}
@Component
public class InventoryListener {
@EventListener
public void handleOrderPlaced {
// 扣库存 —— 不需要知道是谁发的。只关心事件本身
}
}
@Component
public class NotificationListener {
@EventListener
public void handleOrderPlaced {
// 发通知 —— 同上
}
}

S​pring 容器即那个隐形 Mediator，你不需要在 TotalService 里注入所有依赖，只管发布事件即可。DispatcherServlet 同理，它居中协调 HandlerMapping、HandlerAdapter、ViewResolver。让 Controller 完全专注业务逻辑。

三个真实的坑

Pit 1：上帝中介者

Mediator 把太多职责塞进去，就会变成“上帝对象”。例如某项目里的 C​hatMediator 同时负责路由、敏感词过滤、使用者权限、持久化、未读计数、@提醒、文件上传等十余功能，一行代码改动可能影响全局运行时行为。

Pain point: 维护难度极高。一次改动导致不可预期错误，代码审查几乎停滞。

解决思路： 将 Mediator 按职责拆分： - 路由层 - 过滤链 - 持久化层 - 通知层 每层只关注自己的职责，从而避免“上帝”膨胀。

Pit 2：不该使用 Mediator 的地方用了它

If two components have a simple one‑to‑one call。引入 Message Queue 会无端增加异步延迟和运维负担，而解耦收益几乎为零。

Pain point: 业务响应时间增长 + 难以定位错误根因。因为请求已经跨越了异步边界，却没有真正解决耦合问题。

判断标准： 

• M×N ≥ 6才考虑 Mediator；
• M×N ≤ 2 且交互稳定时直接调用更高效。

Pit 3：把消息队列当作银弹

A team 为了解耦硬性要求在 CRUD 程序里铺满五个 Topic；结果排查问题时要在多个服务之间跳来跳去；甚至出现 “消费端忘记 ACK” 导致积压告警频繁触发。"解耦" 成了 "时间耦合" 与 "运维耦合" 的新来源。

Pain point: 看似解耦，却引入了可靠性、安全性还有监控成本的新挑战；团队花费大量时间在 “消息丢失/重复消费” 上，而不是业务创新上。

什么时候该用 Mediator 模式？怎么说呢，

• M×N 的交互逻辑频繁变化： 比如聊天程序里的禁言/黑名单/撤回等规则不断迭代；集中管理能让修改一次生效全部场景，大幅降低回归风险。
•  GUI 框架里同一 Button 在对话框和表单里的行为截然不同；换掉 Mediator 即可复用 Button 本身。无需改动 UI 控件代码.
•  微服务之间通过 Topic 解耦，仅需约定好协议即可；其实，新增或下线使用者不会影响生产者，实现平滑演进.

一句话

Mediator 模式不是让你随手加一层「中间件」，而是"把对象间混乱的交互关系封装成可独立维护的协调单元". 消息队列、Spring Event、GUI 框架——都在做这件事。只是没人叫它设计模式而已.

---

我在做一个用卡皮巴拉讲设计模式的微信小程序「爪爪代码冒险记」，每个设计模式用漫画加答题方式讲。Mediator 模式在里面出现的是「卡皮巴拉餐厅的传菜员」——厨师和顾客不直接交流，由传菜员居中协调。感兴趣的话搜索「爪爪代码冒险记」了解更多。

`

---