1. 项目概述1.1 中介者模式是什么它到底解决了什么痛很长一段时间里我在写业务代码时最头疼的不是某个算法多难写而是对象与对象之间的通信关系越来越乱。举个例子你做一个表单页面里面有几个输入框、一个下拉框、一个日期选择器、一个提交按钮。它们之间互相影响输入框A的值决定下拉框的选项下拉框的选中值又决定日期选择器的禁用状态按钮的可用性又依赖前面所有组件的合法性。如果你直接在组件里互相调用代码很快就会变成一团乱麻每个组件都持有其他组件的引用任何一个小改动都要牵动好几个地方。你改一个输入框的校验逻辑可能不小心破坏了另一个组件的联动。这种网状结构维护成本极高改起来战战兢兢。中介者模式Mediator Pattern解决的就是这个问题。它是行为型设计模式中的一种核心思想用一个对象封装一组对象的交互方式让这些对象不再显式地互相引用而是统一通过一个中介者来通信。简单说就是把多对多的网状关系改造成一对多的星形关系中间的节点就是中介者。用生活来类比最直观一群人在一个群里聊天每个人不需要保存其他人的联系方式只需要往群里发消息别人自然能看到。群就是中介者。如果没有群每个人都要维护一个长长的联系人列表还要知道谁在什么时候方便接收什么消息那是灾难。这个模式特别适合那些交互规则复杂、对象数量多、后续还可能频繁调整交互逻辑的场景。我最初是在做某个跨平台桌面客户端时接触它的当时的组件通信简直是一锅粥重构引入中介者之后整个模块的复杂度一下子降下来了可维护性提升非常明显。1.2 什么人适合读这篇如果你已经掌握基本的面向对象知识知道类、接口、继承写过一点实际业务代码那这篇很适合你。我会从最简单的动机讲起逐步拆解角色、代码实现再讲它和观察者、门面模式这些容易混淆的模式有什么区别最后分享我在实际项目中踩过的坑和排查思路。无论你是写后端服务、桌面客户端还是做前端页面中介者模式都有它的用武之地关键是要判断准时机——过度设计同样是一种负担这一点我会在后面的反模式部分重点讲。文章里的代码示例我用 Java 写但思路完全不限于 Java你用 C#、Python、TypeScript 都能轻松迁移。2. 整体设计与思路拆解2.1 为什么不用直接引用看看网状结构是怎么腐化的先展开讲讲“直接互相引用”为什么危险。很多初学者觉得几个对象嘛我直接持有对方的引用调用对应方法不就行了何必再引进一个中介者多一个类出来不是更复杂吗短视地看直接调用确实简单。但一旦系统膨胀麻烦就来了。假设你现在有 6 个对象需要互相通信最极端的场景是每个对象都要和其他 5 个对象交互那么你最多需要维护 6 * 5 / 2 15 条交互关系。每个对象要持有 5 个其他对象的引用。任何一条交互规则的变化可能只需要改一个方法但如果是交互拓扑变化比如某个对象不再需要和另一个通信了你就得同时改两边还不能漏掉。当对象数量变多这种链接会指数级增长。开发人员在做需求变更时几乎无法评估改动的影响范围。你可能只改了一个小小的校验规则结果联动行为全线崩盘。更麻烦的是这种网状协作逻辑是分散在各个对象内部的你想找一个完整的业务流程得对象之间来回跳像在迷宫里找出口。引入中介者之后对象之间不再直接引用对方每个对象只认识中介者。6 个对象的关系从 15 条降到了 6 条每个对象只连中介者。所有交互逻辑被收敛到中介者内部。一旦业务规则变化你只需要改中介者一个类其他对象基本不用动。这就是“封装变化”的典型思路。2.2 中介者模式的核心角色分配中介者模式其实只有四个核心角色非常清晰角色职责类比抽象中介者定义同事对象之间通信的接口群聊的规则协议具体中介者实现协调逻辑持有所有同事对象的引用群主/群管理者的实际调度抽象同事定义同事类的公共接口持有中介者的引用群成员的基本规范具体同事实现自身业务通过中介者与其他同事通信真正的群成员这里有个关键点同事对象之间是不认识彼此的。它们只持有中介者的引用一旦自己的状态发生变化就通知中介者中介者收到消息后决定是否调用其他同事的方法。同事类的代码依然保持着自己的核心业务逻辑但“跟谁协作”“怎么协作”这些事全部甩给了中介者。这种设计的精妙之处在于职责切分非常清楚。同事对象只关心“我自己”中介者关心“大家怎么配合”。你要是想调整协作规则完全不用碰同事类只动中介者开发效率显著提升。2.3 选型之前的灵魂拷问这个模式适合我的场景吗用了这么多年我总结出几个判断信号满足其中两三条就可以考虑中介者模式系统中存在大量对象并且彼此之间有复杂的、动态变化的交互关系交互逻辑经常需要调整而你不希望每次调整都牵连大量对象对象之间复用困难因为每个对象都耦合了太多其他对象的信息你发现自己的代码里到处都是xxx.method()这种跨对象调用逻辑散落各处但也要警惕滥用。如果只是两三个对象的简单交互强上中介者就是纯纯的过度设计多写一个抽象层除了增加理解成本没有任何实际收益。模式是为了解决问题不是为了炫技。我见过强行用中介者把简单逻辑搞复杂到没人敢动的项目那是灾难。3. 核心细节解析与实操要点3.1 抽象中介者接口该怎么设计先看第一个关键设计点抽象中介者的接口方法粒度。很多人设计成一个大而全的notify所有消息都走同一个方法然后在中介者内部用 if/else 判断消息类型。这种方式不推荐因为同事数量一旦多起来这个notify方法会变成巨型方法到处都是分支判断可读性极差。我推荐接口方法按业务语义来拆分。比如聊天场景有“发送消息”“用户上线”“用户下线”这些不同的交互行为在抽象中介者里就定义对应的方法sendMessage、userConnected、userDisconnected。这样每个方法承担的职责清晰后续扩展新交互时只要加一个抽象方法逼迫所有中介者实现类去适配编译期就能暴露出遗漏。需要注意的是抽象同事类里面持有的是抽象中介者引用而不是具体中介者。这是依赖倒置原则的直接应用高层模块中介者和低层模块同事都依赖于抽象不依赖具体实现。这样后期替换中介者实现就非常容易比如从同步通信改成异步消息队列同事类完全无感知。3.2 具体中介者内部怎么管理同事具体中介者通常要持有一个同事的集合常见的有List、Map按业务需要来选。Map更常用因为你可以通过 key 精确定位同事。比如工单系统里每个处理节点用一个键标识中介者拿到事件后就能准确找到下一步该通知谁。注册逻辑也很讲究。有两种方式一种是同事对象在构造时主动把自己注册到中介者另一种是中介者提供register方法由外部统一装配。我实际项目里更喜欢第二种因为装配关系集中在一处比如启动配置模块方便排查问题。你一眼就能看出系统里有哪些同事、谁注册了谁没注册而不是翻遍每个构造函数才能拼出全貌。还有一个细节同事与中介者的关联时机。假设同事类构造时需要调用中介者的某个方法但此时还没注册完成可能产生空指针或逻辑遗漏。所以注册完成后建议再触发一个初始化通知让中介者对刚进来的同事做一次状态同步确保它一上线就处于正确的环境里不至于漏消息。3.3 同事类的三个务必同事类看起来简单但写起来有三个务必务必只通过中介者通信这是铁律。一旦同事之间绕过中介者直接建立了引用模式的根基就被破坏了退化成普通网状结构。务必把“自己状态的变更”封装成方法比如changeValue内部先更新自己的状态再调用中介者的更新方法。别让外部直接乱改内部字段破坏封装性。务必保持同事类的可独立测试性同事类只依赖抽象中介者接口所以在单测时你可以用一个 Mock 中介者去替换真实中介者验证同事类是否正确发出了通知。这一点对大型项目特别有价值。3.4 方法调用顺序的潜在坑中介者调同事方法时顺序很讲究。比如一个搜索框联动场景输入关键词 → 刷新搜索结果列表 → 更新状态栏“共找到 X 条结果”。如果先刷新列表再触发状态栏那状态栏还能拿到列表的最新数量如果反过来状态栏就会显示上一次的数据。我在实际开发中遇到过这种顺序错乱导致的诡异 Bug而且特别难排查因为每个同事单看都是对的。后来我养成一个习惯在中介者的核心协调方法里先写注释清楚每个步骤的先后依赖关系再严格按照依赖顺序调用绝对不靠“感觉”排代码顺序。必要时可以引入状态流转图来辅助用纯文字描述流程顺序即可确保后续维护者不踩同样的坑。4. 实操过程与核心环节实现4.1 聊天室场景的完整 Java 实现直接上一个我觉得最容易理解的经典场景——聊天室。我们有多个用户用户通过聊天室这个中介者互相发消息。先定义抽象同事// 抽象同事类 public abstract class User { protected Mediator mediator; protected String name; public User(Mediator mediator, String name) { this.mediator mediator; this.name name; } public abstract void send(String message); public abstract void receive(String message); public String getName() { return name; } }再定义抽象中介者接口// 抽象中介者 public interface Mediator { void sendMessage(User sender, String message); }具体中介者实现// 具体中介者 public class ChatRoom implements Mediator { private ListUser users new ArrayList(); public void register(User user) { if (!users.contains(user)) { users.add(user); } } public void unregister(User user) { users.remove(user); } Override public void sendMessage(User sender, String message) { // 广播给所有用户除了发送者自己 for (User user : users) { if (user ! sender) { user.receive(sender.getName() : message); } } } }具体同事类// 具体同事 public class ChatUser extends User { public ChatUser(Mediator mediator, String name) { super(mediator, name); } Override public void send(String message) { mediator.sendMessage(this, message); } Override public void receive(String message) { System.out.println(name 收到消息: message); } }使用方式ChatRoom chatRoom new ChatRoom(); ChatUser alice new ChatUser(chatRoom, Alice); ChatUser bob new ChatUser(chatRoom, Bob); ChatUser carol new ChatUser(chatRoom, Carol); chatRoom.register(alice); chatRoom.register(bob); chatRoom.register(carol); alice.send(大家好我是Alice);输出结果就是 Bob 和 Carol 各自收到了 Alice 发来的消息而 Alice 自己不会收到。这个例子把中介者最核心的“广播转发”暴露得很清楚用户对象之间完全不存在直接引用它们只跟 ChatRoom 打交道。4.2 表单联动场景比聊天室复杂十倍的真实体验聊天室是广播模型太简单了。我再写一个贴近业务的场景订单表单的联动校验。假设表单里有三个关键组件客户类型下拉框、折扣率输入框、订单金额输入框还有一个提交按钮。业务规则如下客户类型选择“VIP”时折扣率输入框可用否则禁用折扣率只能在 0 到 0.3 之间订单金额必须大于 0且金额超过 1000 时才允许提交“大额订单”按钮姑且算一个特殊标记提交按钮的可用性取决于金额、折扣率是否都合法我先把交互规则写在纸上翻译成中介者的协调逻辑public class OrderFormMediator implements Mediator { private CustomerTypeSelect customerTypeSelect; private DiscountInput discountInput; private AmountInput amountInput; private SubmitButton submitButton; // register 方法省略逻辑就是为这些字段赋值 Override public void notify(Component sender, String event) { if (sender customerTypeSelect) { // 客户类型变化时控制折扣输入框的状态 if (VIP.equals(customerTypeSelect.getValue())) { discountInput.setEnabled(true); } else { discountInput.setEnabled(false); discountInput.clear(); } } else if (sender discountInput || sender amountInput) { // 金额或折扣变化更新提交按钮状态 validateAndUpdateSubmit(); } } private void validateAndUpdateSubmit() { boolean amountValid amountInput.getValue() 0; boolean discountValid discountInput.isEnabled() ? discountInput.getValue() 0 discountInput.getValue() 0.3 : true; submitButton.setEnabled(amountValid discountValid); } }你会发现各个 UI 组件自己根本不关心别的组件怎么联动。客户类型下拉框只管自己选中了什么折扣输入框只管自己能输入什么提交按钮只管自己可不可用。真正把所有规则串起来的是OrderFormMediator。以后产品经理再加规则比如“订单金额超过 5000 时折扣上限调整为 0.5”你只需要在validateAndUpdateSubmit里加一行判断其他组件代码一行都不用改。这个例子才算展示了中介者模式在真实业务里的价值不是简简单单的广播而是把复杂的业务编排逻辑集中在一个可控的位置。4.3 实现过程中我用到的几个调试技巧写中介者代码最怕什么最怕逻辑分支太多跑起来不知道哪一步被触发了。我分享三个实操技巧第一个技巧日志标注在中介者里不放在同事类里。每次 notify 进来先打印“收到来自X组件的Y事件”。这样你在日志里能完整看到事件流向。如果同事类里也打印日志会混乱且重复排查问题反而更困难。第二个技巧给每个注册的同事起个可读的名字。如果中介者内部用MapString, Component来存key 一定要是业务语义的名称比如customerTypeSelect、submitButton不要用comp1这种序号。不然调试时日志里全是莫名奇妙的编号自己都看不懂。第三个技巧在中介者里实现状态快照。这个方法比较高级。有些交互场景比较复杂状态是逐步变更的我希望能在中介者里加一个snapshot()方法把当前所有同事的关键状态汇总成一个 DTO 存下来。一旦出现 Bug我可以对比前后快照迅速定位是哪个组件的哪个状态出了问题。这个技巧我在处理某个复杂的权限联动模块时帮了大忙。4.4 异步化改造中介者模式如何拥抱消息队列前面聊的都是同步调用。但在真实系统中同事之间的协调逻辑不一定需要同步完成。比如某个操作特别耗时会阻塞 UI 线程或者某些通知本来就允许延迟那我们可以把中介者的实现改成异步消息驱动。具体做法是中介者的内部协调逻辑不直接调用目标同事的方法而是把“发给谁、什么事件、什么数据”打包成一个消息对象投递到队列里后台线程池处理队列再调用对应的同事方法。这样的好处很明显主流程不卡顿用户体验提升同事之间进一步解耦中介者也变成了一个可替换的调度枢纽后续如果想把通信方式从进程内改成跨服务只要替换掉队列实现对同事类完全无影响我实际做过一次改造把一个原本同步联动、导致 UI 卡顿的功能改成中介者 轻量级任务队列的组合。改造后界面流畅了代码结构反而更清爽。这是一条值得推荐的升级路径也充分说明了“抽象中介者接口”有什么好处——实现怎么换都行。5. 应用场景与影响范围分析5.1 哪些业务场景天然适合中介者模式中介者模式在业界广泛应用常见的典型场景包括聊天室/群组通信消息统一经转发用户不需要知道彼此地址界面组件联动表单、仪表盘、控制面板里各种控件的互相影响工作流编排多个处理节点按顺序/条件流转由一个调度中枢控制航空/交通管制系统飞机之间不直接通信统一由塔台调度这是中介者模式最经典的真实世界例子企业级消息总线微服务之间通过一个总线通信消息中间件其实就是一个分布式的中介者我做过的最典型的一个项目是某电商后台的促销规则引擎。促销规则包括满减、折扣券、包邮、赠品等多条规则作用于同一商品时最终结算价格怎么算规则之间不是简单叠加有些规则互斥有些规则有优先级。这些规则如果互相协商会乱成一团。后来我把规则执行引擎设计成中介者每种规则是一个同事规则引擎统一协调计算顺序、互斥判断、结果合并。新增一种规则只需要做一个同事注册进来改规则协调逻辑只动引擎后面迭代效率高多了。5.2 它和门面模式、观察者模式到底怎么区分这是很多人最容易混淆的地方我重点讲。中介者模式 vs 门面模式外观模式门面模式是结构型模式目的是为复杂子系统提供一个统一的简单入口它是单向的——客户端通过门面访问子系统但子系统并不知道门面的存在。中介者模式是行为型模式它是双向的——同事对象之间通过中介者互相通信中介者收到事件后会反向去调用其他同事的方法。一个是入口封装一个是交互中枢职责完全不同。中介者模式 vs 观察者模式观察者模式是一对多的通知关系——被观察者状态变化通知所有观察者。中介者模式更强调多对多的协调。实践中二者经常组合使用中介者内部可以注册很多“监听器”用观察者模式来监听同事的事件中间再通过中介者决策转发。例如一个系统里多个同事都向中介者发送事件中介者内部用事件监听机制观察者处理这些事件再决定通知哪些同事。理解这种组合关系能让你在实战中游刃有余。做个简单的对照表维度中介者模式观察者模式门面模式类型行为型行为型结构型通信方向多对多双向一对多单向客户端到子系统单向核心目的封装对象间交互逻辑状态变化广播简化子系统的访问典型实现中介者对象持有同事集合主题维护观察者列表门面类封装子系统组合调用5.3 中介者模式的边界什么场景用了反而吃亏没有任何模式是万能的。基于我的经验下面这些场景用了中介者反而会吃亏对象数量很少交互规则稳定两三个对象固定通信直接引用完全没问题引入中介者是纯增加复杂度。同事对象职责本身差异极大如果同事之间本质上没有公共接口勉强抽象出一个抽象同事类代码会很别扭反而破坏阅读性。对性能极其敏感的高频通信中介者成了一个中心节点所有消息都经过它如果这个消息路由逻辑复杂会引入额外延迟。像游戏引擎里每帧做大量实体通信用中介者就不合适更贴近实际的做法是直接用 ECS 架构。系统规模巨大中介者本身变成上帝对象当所有规则都堆在一个中介者里中介者就成了几千行的上帝类改哪里都怕炸。这时候需要做的是拆分中介者——用多个小中介者分别负责不同模块而不是强行硬撑一个巨型类。判断的底层逻辑是模式是用来管理复杂度的不是用来制造复杂度的。如果你面对的交互复杂度根本不高或者中介者引入后反而让模块更难理解那就要果断放弃这个模式回到最朴素的写法。6. 常见问题与排查技巧实录6.1 同事对象注册遗漏导致功能“静默失效”这个 Bug 特别隐蔽。有时候你写完代码运行起来发现某些组件之间没有任何联动怎么查都查不出逻辑错误。最后才发现是某个同事对象忘了注册到中介者里。中介者的注册表里根本没有它它发的通知自然没人响应。排查技巧在中介者的notify方法入口统一打印日志带上事件来源组件名。如果日志里根本没有某个组件的发事件记录那基本能肯定是注册问题了。我还会封装一个getComponentCount()方法方便在断点时快速核对对象列表数量。预防措施把注册逻辑集中在配置阶段而且注册完成后用一个assertAllRegistered方法做一次完整性校验确保所有预期的同事都已注册成功。6.2 循环通知把系统拖进死循环有一种情况同事 A 发事件 → 中介者通知同事 B → B 的更新操作又触发新事件 → 中介者又通知 A……如果中间没有设置终止条件消息会在 A 和 B 之间来回弹射轻则日志刷屏重则栈溢出或线程池被耗尽。我当时在一个复杂的连锁下拉框场景里遇到过省份变化→更新城市列表→城市变化触发更新区县列表→区县变化又反过来刷新省份下拉的高亮状态→省份高亮变化又触发省份事件。结果数据一加载直接死循环。解决方案有两个层次。第一层是业务层面加防护在事件分发的源头检查新旧值值没变化就不发通知。第二层是架构层面加保护在中介者内部设置一个分发深度计数器超过阈值比如 10就抛异常或直接打断分发并告警。我喜欢两层都做第一层保证正常场景不空转第二层防御意想不到的隐患。6.3 中介者变成上帝类之后怎么办随着业务不断迭代中介者的代码会越来越长。我见过一个中介者最后膨胀到几千行方法几十个每个方法里一长串 if/else后面接手的同事看到这种代码直接头皮发麻。这时候要认识到中介者不是越大越好而是越内聚越好。我的处理办法是拆分子中介者。比如一个订单表单页面我可以拆成“客户信息中介者”“支付信息中介者”“商品信息中介者”然后让一个总控对象去配置这些子中介者之间的协作关系。每个子中介者负责一小块交互逻辑职责明确可以独立测试总控对象只做简单的组装和转发。另外一个降低上帝类的思路是把纯数据的状态存储从中介者里剥离开来放到专门的状态模型类中。中介者只关心逻辑编排不关心数据长什么样、存在哪个属性里。这让中介者的代码聚焦于“什么时候该做什么”而不是被一堆状态数据的存取淹没。6.4 单元测试中中介者的顺序问题中介者最难测的是时序问题。两个事件先后到达的顺序可能导致最终状态完全不同。比如客户类型选 VIP → 折扣输入框可用 → 填了 0.2 → 金额填 200 → 提交按钮应该可用但如果客户类型事件比金额事件晚到等于折扣输入框从禁用变成启用时之前填的 0.2 还在不在不同行为在不同实现里表现完全不同。我写测试时一般覆盖这三个场景正常时序事件按业务预期顺序到达验证最终状态逆序到达事件顺序打乱验证系统是否依然处于安全状态重复事件同一事件发送两次验证不会产生副作用这三个场景能覆盖绝大多数真实业务里出现的问题。我还习惯用 Mock 对象做同事类的假实现让测试聚焦于中介者本身的编排逻辑不掺入真实同事的业务细节大大提升测试的稳定性和定位问题的效率。6.5 快速自查清单我把这几年写中介者踩过的坑汇总成了一份检查清单每次写完这个模式的代码我都会对照过一遍[ ] 同事对象之间是否仍然存在直接引用必须没有[ ] 所有同事是否都在中介者注册完毕后才被允许开始交互[ ] 事件类型是否有清晰的常量定义避免魔法字符串满天飞[ ] 中介者是否按业务语义拆分了方法避免一个万能 notify 巨型方法[ ] 是否设置了循环通知的防护阈值[ ] 每个同事是否都只依赖抽象中介者接口便于替换实现和单元测试[ ] 中介者内部的调用顺序是否有注释说明依赖关系[ ] 是否考虑过异步化改造的可能根据项目实际情况决定不可盲目上7. 实操心得与扩展思考7.1 我实际用下来最舒服的写法说了这么多理论最后聊点我个人的手感经验。中介者模式写多了我最喜欢的一种组合是抽象中介者 事件枚举 具体中介者 同事注册表。事件枚举非常关键。很多初学者喜欢用字符串类型来区分事件比如change、click但字符串容易写错、编译器不检查、重构时改一处漏一处。我用 Java 枚举定义好所有事件类型同事类发通知时只能传合法的枚举值编译器直接卡住错误效率上来了改代码时的心理压力也小了。同时我会在具体中介者里维护一个MapClass? extends Component, ListComponent这种多维注册表方便按组件类型批量分发。虽然多数场景只是简单遍历但遇到“给所有输入框统一触发校验”这种需求时这种结构让代码非常清晰。7.2 中介者模式和事件驱动架构的关联如果往更高的架构层看中介者模式和事件驱动架构EDA的思路是一脉相承的解耦事件生产者与消费者通过一个中间媒介路由事件。你在微服务架构里遇到的消息中间件、发布订阅系统、事件总线本质上都是分布式版的“中介者”。理解了这一点你会突然发现中介者模式不是孤立的它和主流架构思想是互通的。在单体应用里用中介者模式管理的对象交互逻辑到了微服务架构里完全可以平移为消息队列的 Topic 路由规则、事件总线的订阅分发策略。学一个模式其实是在为理解更高层次的架构打下基础。7.3 未来扩展思路如果你已经对基础用法很熟了下一步可以试试这几个方向组合把中介者和观察者组合内部监听事件外部做协调决策异步化把中介者的内部调用改成异步任务队列提升交互流畅度拆分把大型中介者拆解为由多个小中介者组成的“协调网络”每个小中介者职责单一序列化把中介者的协调过程建模为状态机用显式的状态流转替代散落的事件判断领域驱动设计一个聚合根其实可以看作某个范围内的中介者管理聚合内部各实体之间的协作规则我个人在中介者的异步化改造上受益最多。那是某个跨平台客户端的组件通信模块本来所有联动都走同步调用用户操作一多就卡。后来我把中介者的实现替换成基于轻量级任务队列的异步版本所有同事类的代码几乎没动UI 的响应速度提升明显。这个案例让我对“用抽象约束底层变化”有了非常直观的感受。7.4 最后分享一个实用小技巧如果你记不住什么时候该用中介者就记一个判断口诀“交互是否复杂到让你觉得对象应该有一根神经中枢”如果你在写代码时反复想“这里要不要改那个对象的方法”“那边要不要通知这几个组件”那就是时候考虑引入中介者了。但如果只是两三个对象一次性的简单调用收一收炫技的心老老实实直接调用就好。设计模式给你的不是更多的复杂度而是在复杂度真来的时候有条不紊地把它管理起来。这一点想通了用什么模式都不会跑偏。