中介者模式通过引入中心化事件分发对象，使组件仅与中介者通信，避免多层透传和相互引用；它解决父组件props臃肿、兄弟组件通信依赖父级、多模块响应硬编码耦合三大问题，实现解耦与可维护性提升。

用中介者模式把散落在各层组件里的事件转发逻辑收束到一个中心对象里，组件只跟中介者通信，不再层层透传或互相引用。

为什么多层封装容易掉进“事件地狱”

当 UI 组件嵌套变深（比如 Button → Form → Page → Layout → App），事件处理常出现三种典型问题：

• 父组件被迫暴露大量回调 props，只为把子组件的点击、输入等事件“接力”传上去
• 兄弟组件想通信，得靠共同父级中转，父组件逻辑越来越臃肿，变成“事件搬运工”
• 某个事件要触发多个不相关模块（如提交成功后刷新列表 + 关闭弹窗 + 发送埋点），硬编码耦合导致修改一处牵动全局

中介者怎么打破这层嵌套依赖

核心是让所有组件都只认识一个“群聊管理员”，而不是彼此加好友。这个管理员就是中介者实例：

• 每个组件在初始化时注册到中介者，告诉它“我叫什么、我能发哪些事件、我想监听哪些事件”
• 组件触发行为时，只调用 mediator.notify("submit", data)，不关心谁来响应
• 中介者内部按规则分发：比如把 "submit" 同时通知表单校验模块、API 调用模块、UI 状态模块
• 新增一个响应方（比如加个日志上报）只需在中介者里注册新监听，原组件代码零改动

一个轻量可行的实现思路（以 JavaScript/TypeScript 为例）

不需要框架支持，几行代码就能搭出骨架：

• 定义一个 EventMediator 类，内部用 Map 存储事件名 → 回调数组的映射
• 提供 on(event, handler) 注册监听、emit(event, payload) 触发通知、off(event, handler) 可选解绑
• 各组件构造时传入同一中介者实例，通过 mediator.on("userUpdated", this.handleUserUpdate) 订阅
• 深层子组件调用 mediator.emit("userUpdated", { id: 123 })，顶层状态管理器或日志模块自然收到

注意避开两个常见坑

中介者不是万能胶，用错反而加重负担：

• 别把所有函数调用都塞进中介者——仅限真正需要跨组件协作的事件，比如“登录态变更”“全局错误”“导航跳转”
• 避免中介者变成上帝对象——如果一个 notify 调用触发了 8 个模块的副作用，说明业务职责没理清，该拆分的交互逻辑还是得收敛到更小的领域中介者里