中介者模式通过引入中介者统一调度对象交互，使对象仅依赖中介者而不互相耦合；识别网状耦合信号包括多依赖注入、多模块联动修改、多处补调用及高mock成本；解耦三步为抽离Mediator接口、改造同事类仅持中介者引用、实现具体协调逻辑；需严守边界——中介者只调度不实现、策略隔离、跨系统通信走消息队列、禁止同事类直调；验证标准为新增/关闭功能或替换策略时仅改中介者，同事类零改动。
中介者模式的核心作用，就是把原本散落在各处、彼此直接调用的交互逻辑，集中到一个中介者里统一调度，让对象之间只跟中介者打交道，不再互相依赖。
识别网状耦合的典型信号
当代码中出现以下情况，说明已经陷入高耦合：
- 某个类的构造方法里频繁 new 或注入多个其他服务（比如 OrderService 同时依赖 UserService、InventoryService、SmsSender）
- 改一处逻辑（如用户注册），必须同步动积分、风控、通知、日志等至少三个模块的代码
- 新增功能（如支持微信登录）需要在登录门面、权限校验、埋点、会话管理等多个地方补调用
- 写单元测试时发现一个方法严重依赖其他五六个组件的状态，mock 成本极高
三步完成解耦重构
不重写业务逻辑，只调整通信路径：
Alibabacloud Sdk Client Initialization For Java
下载
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
-
抽离契约接口：定义 Mediator 接口，只声明事件语义，例如
onUserRegistered(User user)、onOrderPaid(Order order)，不暴露实现细节 -
改造同事类：各业务类（UserService、OrderService 等）移除对其他服务的字段引用和构造注入，只保留 Mediator 引用；触发事件时统一调用
mediator.onXXX() - 实现具体中介者：在 ConcreteMediator 中编写协调逻辑，例如“用户注册后，先调积分服务加10分，再异步发短信，最后发 MQ 通知风控”，顺序、条件、异常分支全由它控制
守住中介者的边界
中介者不是万能容器，而是调度中枢，必须划清职责：
- 库存校验仍由 StockService 自己的
check()方法完成，中介者只负责调用它 - 不同场景的通知规则（普通订单 vs 会员订单）用 Strategy 封装，中介者组合使用，避免堆砌 if-else
- 跨系统通信（如通知物流）不走内存中介者，改用 Kafka 或 RocketMQ，保持物理隔离
- 禁止同事类之间私聊——代码审查中拦截类似
userExtService.enrich(user)这样的直调语句
验证解耦是否真正生效
重构完成后，看三点实际变化：
- 想增加“注册送优惠券”？只需在中介者中加一行
couponService.grant()，其余所有业务类完全不动 - 要临时关闭短信通道？注释掉中介者里对应那行
smsSender.send()即可，不影响积分、日志等其他流程 - 替换风控策略为灰度版本？只需运行时注入另一个 ConcreteMediator 实现，无需改动任何同事类
