中介者模式的核心价值是解耦对象间网状依赖，通过集中协调逻辑实现可控交互。典型信号包括频繁new其他类、修改一处需多处联动、新增参与者需多点修改等；重构需抽离契约、改造同事类、实现中介者，并避免上帝类、私聊和跨系统直连。

中介者模式的核心价值，不是加一层转发，而是把“谁该响应什么”从对象内部剥离出来，集中到一个可控的协调点上。当多个对象频繁互调、改一处牵动一片时，它就是最直接的解耦杠杆。

识别网状耦合的典型信号

以下情况说明对象间已形成隐性依赖网：

• 某个类里反复 new 其他类实例，或持有大量其他类的引用
• 修改 A 类的一个方法，必须同步调整 B、C、D 类的对应逻辑
• 新增一个参与者（比如加个通知模块），需要在原有七八个类里补调用入口
• 单元测试难写——因为一个对象的行为强依赖于其他对象当前状态

重构三步走：从紧耦合到中介协调

不重写业务逻辑，只调整交互路径：

• 抽离交互契约：定义 Mediator 接口，只声明“谁会触发什么事件”（如 onOrderPlaced()、onStockUpdated()），不涉及具体实现
• 改造原有对象为同事类：每个类不再直接调用别人，只向中介者发消息；同时移除对其他类的字段引用和构造注入
• 实现具体中介者：在 ConcreteMediator 中编写协调逻辑——比如订单创建后，先查库存，再决定是否触发扣减、发短信、推消息，顺序和分支全由它控制

避开常见重构陷阱

中介者容易变成“上帝类”，关键要守住边界：

• 中介者只做调度，不做业务计算——库存校验逻辑仍在 StockService 里，中介者只调用它的 check() 方法
• 同一类事件的不同处理，用策略模式拆分，别堆在中介者的 if-else 里
• 跨系统通信（如订单服务通知物流）不走内存中介者，改用 MQ 或事件总线，保持物理隔离
• 同事类之间禁止绕过中介者私聊——可在代码审查中加入检查规则，比如禁止出现 xxxService.doYyy() 这类直调语句

效果验证看这三点

重构是否成功，不看代码行数，看可维护性变化：

• 新增一个“积分到账”动作？只需在中介者里加一行调用，不碰订单、用户、账户任一原有类
• 想临时屏蔽短信通知？注释掉中介者中一行 smsSender.send() 即可，不影响其他流程
• 测试订单创建流程？Mock 一个空实现的 Mediator，验证它是否按预期发出了哪些事件