中介者模式用于解耦因共享状态而产生隐式依赖的对象间通信，而非协调变量本身；它通过统一调度事件（如onOrderPaid）来编排服务调用顺序，不保存状态、不做计算，仅负责“何时调、调谁、按什么顺序”。
中介者模式不是用来协调“变量”本身，而是协调持有或操作这些变量的对象之间的通信。所谓“变量的中介者模式”实际是误读——真正解耦的是对象间因共享状态（如订单状态、库存数量、用户积分等）而产生的隐式依赖。关键在于把“谁改了什么变量、谁该被通知、谁要联动响应”这一系列逻辑，从散落在各处的类中抽出来，统一由中介者调度。
识别该用中介者的信号
当出现以下情况时，说明变量交互已演变为对象网状耦合：
- 一个类频繁读写多个其他类的字段（比如OrderService直接调用StockService.getAvailableQty()、再调用UserAccountService.addPoints()）
- 修改某个状态变量（如order.status = "PAID"）后，必须手动在三四个地方同步更新关联变量（库存减扣、通知发、积分加）
- 新增一个下游动作（比如“下单成功后发优惠券”），需要在订单、用户、营销三个服务里分别加调用代码
- 单元测试时，想验证“支付成功是否触发扣库存”，却不得不构造完整 StockService + NotificationService + UserService 实例
三步重构：把变量联动逻辑收归中介者
不改业务逻辑，只改交互路径：
- 定义契约接口：声明“事件”而非“操作”。例如：Mediator.onOrderPaid(Order order)、onStockReserved(String sku, int qty)。接口里不出现具体类名或字段名，只体现业务语义
- 改造同事类：每个类移除对其他类的字段引用和注入；不再直接读写对方变量；改为调用mediator.onXXX(...)发出事件。例如 OrderService 支付成功后只发mediator.onOrderPaid(order)，不再碰 StockService 或 AccountService
- 实现具体中介者：在OrderFlowMediator中编写协调逻辑。例如：onOrderPaid() 方法内顺序调用stockService.reserve(order.items) → 检查结果 → 成功则调用accountService.addPoints(...) → 再调用smsSender.send(...)。变量变化仍由原服务执行，中介者只决定“何时调、调谁、按什么顺序”
避开常见陷阱
中介者容易变重，守住三条边界：
- 它不保存业务状态变量（如不存currentStock或userPoints），只持有所需服务的引用
- 它不做校验或计算——库存是否足够？由StockService.canReserve()判断；积分怎么算？由PointCalculator.calculate()返回。中介者只转发和编排
- 跨进程/跨服务的变量同步（如订单库更新后通知物流库）不用内存中介者，改用消息队列或事件总线，保持物理隔离
效果立竿见影
重构后，变量联动变得可读、可测、可开关：
- 加个“下单送抽奖码”？在中介者onOrderPaid()末尾加一行lotteryService.generateCode(order)，不碰任何原有类
- 临时禁用短信？注释掉中介者里smsSender.send()那一行，其他流程照常运行
- 测试支付联动逻辑？Mock 一个空实现的 Mediator，断言它是否收到了onOrderPaid()，以及是否按预期调用了stockService.reserve()和accountService.addPoints()
