解决循环引用并演进中介者模式需四步：先提取共享契约、接口抽象与延迟导入以切断依赖闭环；再识别协同业务事件；接着构建只调度不决策的轻量中介者；最后通过新增/屏蔽/测试验证解耦效果。
解决模块化项目中的循环引用，同时向中介者模式演进，本质是做两件事：先打破编译期/导入期的依赖闭环，再把运行时的交互逻辑从对象网状调用中抽离出来，集中到一个协调点。这不是单纯“加个中介类”，而是结构升级——从互相喊话，变成统一听指挥。
第一步：切断循环引用的物理链路
循环引用是重构的前提障碍，不解决就无法安全引入中介者。关键不是绕过它，而是让依赖方向清晰、单向：
- 把多个模块共用的类型、接口、事件定义提取到独立包（如 shared 或 contracts），原模块只依赖它，不再彼此 import
- 用接口替代具体实现：A 模块定义
Notifier接口，B 模块实现它；A 通过参数或构造函数接收该接口，不 import B 的包 - 在 FastAPI 或类似框架中，避免顶层直接 import app 实例；改用依赖注入，比如
def get_db(): ...由路由函数按需声明，而非在 models.py 里写from main import app - 对 Python/JS 中难以拆分的场景，启用延迟导入——把
import放进函数体内，仅在真正需要时加载
第二步：识别并收敛交互逻辑
循环引用往往掩盖着更深层的问题：多个模块正在协同完成同一业务流程，却没人统筹。这时要问：
- 哪些操作总是一起发生？比如“下单”必然触发“扣库存”+“发通知”+“更新用户积分”
- 哪个模块每次修改，都迫使其他三四个模块跟着改？这说明协调逻辑散落各处
- 新增一个动作（如加“发送企业微信消息”）是否要改订单、库存、通知三个文件？那正是中介者该接管的地方
把这些隐含的协作规则显性化，整理成事件清单，例如：onOrderCreated、onStockShortage、onPaymentConfirmed。
第三步：构建轻量中介者，守住边界
中介者不是新业务层，而是调度中枢。它的职责非常明确：
- 只持有同事类的接口引用，不持有具体实现类；所有业务逻辑仍留在原服务中（如库存校验仍在
StockService） - 方法只做三件事：接收事件 → 调用对应服务 → 触发下游事件；不处理 if-else 分支逻辑，复杂分支用策略模式外置
- 禁止跨系统直连：订单服务通知物流，不应走内存中介者，而应发 MQ 消息；中介者只管本进程内协调
- 同事类之间严禁私聊：代码审查时可加入规则，禁止出现
userSvc.updateProfile()这类跨模块直调语句
第四步：验证重构是否真正生效
成功与否，不看中介者类多大，而看日常开发是否变简单：
- 想新增“下单后生成优惠券”？只需在中介者中加一行
couponService.generate(order)，不动订单、用户、支付任一原有模块 - 测试订单创建流程？Mock 一个空的
Mediator，断言它是否按顺序调用了库存检查、通知发送、积分更新这三个方法 - 临时禁用短信？注释掉中介者里
smsSender.send()那一行即可，其余流程照常运行
当新增、屏蔽、测试都变得局部且可控，说明变量耦合已解除，中介者模型真正落地了。
