必须上Mediator的信号是：修改一个类导致多处报错、交互逻辑硬编码散落各处、同一行为重复实现；其核心是Mediator接口只声明响应事件，Colleague基类强制注入中介者且禁用直调，具体中介者须避免业务判断、依赖注入组装、不暴露具体类名。
Mediator 接口 + Colleague 基类 + 具体中介者类，把多对多调用压成一对多，通信逻辑全收口到一个类里。这不是“加一层抽象”图好看，而是当 Payment 开始同时调用 Inventory、Email、Analytics 时，你已经没法安全改其中任何一个了。
什么时候必须上 Mediator？看这三类错误现象
不是所有交互都值得引入中介者。真要上，往往是因为出现了这些信号：
- 修改一个类（比如
UserRepository）后，Ui、Logger、Notification全跟着报错 —— 这是强依赖在反噬 -
Order::create()里硬编码了(new Email())->send()、(new Inventory())->deduct()—— 交互逻辑散落在各处，无法统一拦截或审计 - 新加一个通知渠道（比如钉钉），得改
Payment、Refund、Subscription三个类 —— 同一行为重复实现，违反开闭原则
Mediator 接口和 Colleague 基类怎么写才不翻车？
关键不是“写全”，而是守住两个契约边界。很多团队卡在这一步，写成半吊子中介者，结果耦合没降，还多了一层空转。
-
Mediator接口只声明「它该响应什么」，不暴露「它怎么协调」。例如：public function onUserRegistered(string $userId): void;，而不是public function notifyAndLogAndDeduct(string $userId): void; -
Colleague基类必须强制注入Mediator，且禁止子类绕过。用final public function setMediator(Mediator $mediator)封死重写可能 - 同事类内部严禁出现其他同事类的实例或静态调用，比如
new Email()或Email::send()—— 所有外发动作必须转成$this->mediator->onUserRegistered($id)
具体中介者类里最容易堆屎山的三处
这里集中了 80% 的维护雷区。不是逻辑难，是没人约束写法：
- 别在
UserRepositoryUiMediator::__construct()里直接$userRepository->setMediator($this)—— 如果UserRepository是 Laravel 的 Eloquent 模型，它根本不是你可控的同事类。应只协调你明确定义的ConcreteColleague - 避免在中介者里做业务判断。例如不要写
if ($user->isVip()) { $this->sms->send(); }—— VIP 判定属于领域逻辑，应由同事类自己决定是否触发onUserUpgraded()事件 - 中介者内部调用顺序很重要。比如日志必须在库存扣减成功后记，但
Mediator接口不保证执行顺序。解决方案：用返回值或状态对象串联，或明确约定方法名后缀如afterInventoryDeducted()
为什么 ChatRoom 示例不能直接抄？
网上大量 ChatRoom::sayHello() 静态调用示例，本质是伪中介者 —— 它没解决依赖，只是把网状调用换成了中心辐射调用，同事类依然知道彼此存在（比如 Person 知道 ChatRoom 类名）。真中介者要求：
立即学习“PHP免费学习笔记（深入）”；
- 同事类只依赖
Mediator接口，不依赖任何具体中介者类名 - 中介者构造时通过依赖注入接收同事对象，而非让同事主动注册（避免循环引用）
- 客户端代码负责组装：new
UserRepositoryUiMediator($repo, $ui)，而不是让$repo自己找中介者
漏掉任意一点，就只是给代码套了个“中介者”名字的壳。复杂交互不会变简单，只会变得更难调试。
