中介者模式的核心作用是将对象间网状耦合收束为星型结构，通过统一中介者协调通信；适用于频繁相互引用、修改牵连多处、UI交互复杂及协作冲突等场景，其职责仅限消息转发与调度，不承担业务逻辑。
中介者模式的核心作用，就是把原本散落在多个对象之间、彼此直接调用的耦合关系，收束到一个统一的中介者里。对象不再互相持有引用、不再直接通信，而是只和中介者打交道——网状依赖变成星型结构，修改、测试、复用都更可控。
哪些场景特别适合引入中介者
当出现以下迹象时，说明对象间协作已开始失控：
- 一个类的方法里频繁 new 其他类、或持有大量其他类的引用
- 两个对象修改一处逻辑，却要同步改三四个地方，牵一发而动全身
- UI 组件之间交互复杂：比如点击按钮要更新列表、禁用输入框、刷新状态栏、触发网络请求——这些动作分散在各组件中，难以追踪流向
- 多人协作开发时，经常因“我不该改这个类，但它被另一个类硬编码调用了”而产生冲突
中介者不是万能调度中心
它不负责业务逻辑执行，也不替代服务层或状态管理工具（如 Redux、Pinia）。它的职责很窄：只做协调与转发。
- 组件 A 发送“提交表单”事件 → 中介者接收 → 检查当前状态是否允许提交 → 再通知 B（校验器）、C（API 服务）、D（提示组件）各自响应
- 中介者内部不实现校验规则、不拼接请求 URL、不渲染提示文案——它只决定“谁该在什么时候收到什么消息”
- 如果把业务逻辑塞进中介者，它会迅速膨胀成难以维护的上帝对象
轻量实现的关键设计细节
避免过度设计，从最小闭环开始：
- 用事件总线（Event Bus）或发布-订阅机制作为底层通信载体，比继承抽象中介类更灵活
- 给消息定义清晰命名（如 FORM_SUBMIT_REQUEST、USER_LOGIN_SUCCESS），避免字符串魔法值
- 让对象只订阅自己关心的消息，不被动接收全部广播；中介者不主动推送，只做中转
- 在组件销毁或退出时，务必取消订阅，防止内存泄漏
和观察者、状态管理的区别
中介者聚焦于对象协作流程的解耦，而非数据响应或全局状态同步：
- 观察者模式解决“一个变化，多个响应”，但响应者之间仍可能相互影响；中介者则明确谁发起、谁接收、谁协调
- 状态管理（如 Vuex）管的是“数据从哪来、到哪去、怎么变”；中介者管的是“按钮点了以后，该叫谁、按什么顺序、传什么参数”
- 两者可共存：状态变更由 Store 驱动，而跨模块操作流程由中介者编排
