告别 spaghetti 代码：用 PHP 中介者模式把混乱业务流理顺

写 PHP 业务逻辑久了，难免会碰到这种场景：一个订单状态更新，顺手调了库存扣减、物流生成、短信通知和积分结算。日子一久，每个类里都互相引用，改一处动全身，排查问题像在拆炸弹。这时候硬上策略模式或工厂方法往往治标不治本，真正需要的是给这些“互相认识”的组件安个中间人——中介者模式（Mediator Pattern）。它不改变业务本质，只负责把乱麻般的直接调用收拢成一条清晰的管理线。

想象一个标准的电商履约流程。订单完成时，需要同时触发仓储拣货、运费计算、电子发票开具和用户触达。如果让 OrderService 直接实例化并调用这四个类，代码很快就会膨胀。更头疼的是需求变更：今天加个会员等级校验，明天把短信换成企微推送，核心服务的方法就会变成密密麻麻的条件分支。对象之间过度直连，是系统耦合度飙升的隐形推手，也是导致后期重构成本指数级增长的根源。

引入中介者的核心逻辑并不复杂，落地时重点做好三件事：建立参与者注册表与统一事件分发通道。先把仓储、物流、通知等模块收敛到同一套交互接口里，强制它们只认中介者，切断彼此之间的隐式依赖。接着在客户端侧移除硬编码实例化，将原本散落在方法里的多处调用，替换成一次明确的广播指令 $mediator->fire('order_committed', $context)。中介者握有这张“通讯录”，收到信号后按预设路由逐个唤醒对应组件。为防业务上下文在跨模块传递时丢失，强烈建议用 PHP 闭包封装处理逻辑，直接捕获当前请求需要的数据切片，避免大对象透传拖垮性能。

别把中介者当成万能胶。如果参与方只有两三个，或者调用链条固定不变，强行上中介者只会徒增一层不必要的转发开销。它最适配多对多广播型场景，尤其是业务规则频繁变动、前端聚合层需要快速组装下游能力的中台服务。另外，现代 PHP 生态其实有更成熟的轻量方案，比如 Symfony 的 EventDispatcher 或 Laravel 的事件系统。但当团队暂无消息队列基础设施，且业务强要求同步事务一致性时，手写一个轻量中介者反而更可控、调试路径更短。记住，解耦不是为了追求设计模式的颜值，而是为了让后续接手的人不用先啃三天调用链。

代码写到后期，拼的不是语法熟练度，而是结构设计的克制力。把交叉关系交给中介者打理，让核心业务回归单纯的数据流转与状态判定。下次再遇到“牵一发而动全身”的模块时，不妨停下来画张依赖拓扑图，看看是否只需多建一个路由枢纽，就能把一团乱麻理成井井有条的工作流。好架构从来不是靠堆砌概念养成的，是靠不断砍掉多余连接慢慢磨出来的肌肉记忆。