你有没有过这种经历？接手一个别人写的前端项目，想改个小功能，结果牵一发而动全身——改了购物车组件，商品列表跟着出bug；调了用户信息展示，支付按钮突然失灵。最后发现，组件之间像蜘蛛网一样互相引用，A调用B的方法，B依赖C的状态，C又监听A的事件，简直是个“牵一发动全身”的灾难现场。
我去年就踩过这种坑。当时接手一个电商后台管理系统，前任开发者为了图方便，让所有组件直接互相通信：商品表格组件直接修改筛选组件的状态，分页组件又直接调用搜索组件的接口。结果我只是想加个“批量删除”功能，改了3行代码，整个页面直接白屏，查了3天才发现是某个隐藏的组件引用链断了。后来重构时用了中介者模式，把这些乱七八糟的依赖全拆了，现在就算实习生来改代码，也很少出这种低级bug。
中介者模式到底是个啥？用小区物业的例子给你讲透
其实中介者模式一点都不玄乎，你可以把它理解成“组件之间的物业管家”。想象一下，你住的小区里有100户人家（对应前端的100个组件），如果每家有快递都要自己联系快递员，每家报修都要直接找维修工，那得多乱？但有了物业（中介者）就不一样了——快递来了先放物业，物业通知你去取；家里漏水了告诉物业，物业安排维修工上门。各家各户不用互相打交道，有事都找物业，物业再统一协调资源。
前端里的中介者模式也是这个逻辑。所有组件不再直接通信，而是通过一个“中介者对象”来传递消息、共享数据。比如你做一个音乐播放器，有播放按钮、进度条、音量滑块、歌词显示这4个组件。如果不用中介者，播放按钮点击后要直接调用进度条的start()方法，进度条更新时要直接修改歌词显示的currentTime，音量滑块变化还要通知播放按钮更新状态——4个组件之间会产生6条直接依赖关系（数学里的组合数C4取2=6）。但用了中介者，所有组件只和中介者说话：播放按钮点击后告诉中介者“我要播放”，中介者再分别通知进度条开始滚动、歌词显示开始同步；进度条拖动时告诉中介者“当前时间变了”，中介者再让歌词显示跳转到对应行。这样一来，不管多少个组件，每个组件都只需要和中介者打交道，依赖关系从“蜘蛛网”变成了“星型结构”。
《JavaScript设计模式与开发实践》这本书里有个观点我特别认同：“中介者模式的核心是解耦多对象间的交互，将原本散布在各个对象中的交互逻辑集中到一个中介者对象中管理”。这就像你手机里的“通讯录”——以前你要记每个朋友的电话（组件直接引用），现在只需要记通讯录（中介者），想联系谁查通讯录就行，朋友换号码了也只用更新通讯录，不用挨个通知所有人。
啥时候该用中介者模式？这3个信号一出现就得警惕
不是所有项目都需要中介者模式，用错了反而会增加代码复杂度。我 了3个“该用中介者”的信号，你可以对照着看看自己的项目有没有中招：
反过来，如果你的项目只有2-3个组件，或者组件之间基本不需要通信（比如纯展示型页面），那就别折腾中介者模式了，简单的父子组件传值（props/emit）或者Context API就够用。设计模式这东西，核心是“解决特定场景的问题”，不是为了用而用。
不用中介者模式会咋样？我踩过的3个血坑分享给你
说真的，中介者模式这东西，不用的时候可能觉得“无所谓”，用过一次解决大问题后，你就会发现“真香”。我给你讲讲我踩过的3个因为没用中介者模式而掉的坑，看完你可能就懂它的重要性了。
第一个坑是“组件重名变量冲突”。前年做一个内部管理系统，有两个开发者同时开发“用户列表”和“角色列表”组件，两个人都在组件里定义了一个叫handleSelect的方法，用来处理表格行选中事件。因为两个组件要互相传递选中的ID，就直接互相引用了对方的实例。结果上线后发现，当同时打开两个列表页时，用户列表调用roleList.handleSelect()，执行的却是用户列表自己的handleSelect——因为两个组件实例的方法名重名了，后加载的组件覆盖了前面的。当时排查这个bug的场景我现在还记得：两个人对着代码看了2小时，最后在控制台打印roleList实例才发现，里面的handleSelect居然指向了用户列表组件。如果当时用了中介者，两个组件只需要告诉中介者“我选中了ID”，中介者再把ID分发给需要的组件，根本不会有这种“方法名冲突”的问题。
第二个坑是“需求变更时的连锁反应”。去年做一个活动页，有倒计时器、参与人数显示、剩余奖品数量3个组件，当时图省事，让倒计时结束后直接调用参与人数组件的updateCount()方法，参与人数变化后直接修改剩余奖品数量的left属性。后来产品说“要加一个‘活动未开始时隐藏参与人数’的逻辑”，我就在倒计时组件里加了个判断：if (status === 'notStarted') return。结果上线后发现，剩余奖品数量一直显示“0”——因为参与人数组件的updateCount()没被调用，导致剩余奖品数量的left属性没更新。这就是典型的“直接依赖”导致的问题：修改A组件的逻辑，会影响到不相关的C组件。如果用了中介者，倒计时组件只需要告诉中介者“当前状态是未开始”，中介者再决定要不要通知参与人数组件更新，就算改了倒计时的逻辑，也不会影响到剩余奖品组件。
第三个坑是“单元测试写不下去”。前端项目现在都讲究写单元测试，但如果组件之间互相引用，测试就会变得非常麻烦。我之前给那个“互相调用方法”的电商后台组件写测试时，想测试商品列表组件的删除功能，结果因为它依赖购物车组件的getSelectedItems()方法，我不得不先模拟购物车组件的实例，还要手动设置getSelectedItems()的返回值，光准备测试环境就写了50多行代码。后来重构用了中介者模式，每个组件都只依赖中介者，测试时只需要模拟中介者的方法就行，测试代码量直接减少了60%。这也是中介者模式的一个隐藏好处：让组件更“纯”，更容易测试。
手把手教你在前端项目里实现中介者模式，附Vue/React代码示例
说了这么多理论和踩坑经历，你可能会说“道理我都懂，到底怎么写啊？”别担心，中介者模式的实现其实很简单，核心就3步：创建中介者、注册组件、定义通信规则。我用Vue和React分别写了示例，你可以直接抄作业。
基础版中介者：10行代码实现“组件传话员”
先从最简单的开始，不管你用什么框架，中介者的核心逻辑都差不多。我们先实现一个“基础版中介者”，它就像一个“消息中转站”，组件可以向它“发消息”，也可以“订阅消息”，中介者负责把消息转发给订阅的组件。
// 中介者对象
const Mediator = {
// 存储订阅者：key是消息类型，value是回调函数数组
subscribers: {},
// 订阅消息
subscribe(type, callback) {
if (!this.subscribers[type]) {
this.subscribers[type] = [];
}
this.subscribers[type].push(callback);
},
// 发布消息
publish(type, data) {
if (!this.subscribers[type]) return;
this.subscribers[type].forEach(callback => callback(data));
}
};
就这么10行代码，一个基础中介者就做好了。怎么用呢？比如你有个“搜索框组件”和“结果列表组件”，搜索框输入后要通知列表组件更新数据：
// 结果列表组件订阅"search"消息
Mediator.subscribe('search', (keywords) => {
console.log('收到搜索关键词：', keywords);
// 这里调用列表更新逻辑
});
// 搜索框组件发布"search"消息
document.querySelector('#searchInput').addEventListener('input', (e) => {
Mediator.publish('search', e.target.value);
});
你看，搜索框根本不用知道列表组件的存在，只需要发布消息；列表组件也不用知道谁会发消息，只需要订阅消息。这就是中介者最基础的用法——解耦消息的发送者和接收者。我第一次用这个方法是在一个静态页面项目里，当时有5个组件需要根据用户选择的“主题色”同步更新样式，用这个中介者后，主题色选择器只需要发布“themeChange”消息，其他组件订阅后更新自己的样式，代码量比每个组件互相监听少了一半多。
Vue项目实战：用中介者模式管理跨组件状态
如果你用Vue，可能会说“我用Vuex/Pinia不就行了？”确实，状态管理库能解决部分问题，但对于“非全局状态的组件通信”或者“临时交互逻辑”，中介者模式会更轻量灵活。我在Vue项目里习惯把中介者封装成一个插件，这样所有组件都能通过this.$mediator访问。
先创建一个mediator.js插件：
// src/plugins/mediator.js
export default {
install(Vue) {
const mediator = {
subscribers: {},
subscribe(type, callback) {
if (!this.subscribers[type]) this.subscribers[type] = [];
this.subscribers[type].push(callback);
},
publish(type, data) {
if (!this.subscribers[type]) return;
this.subscribers[type].forEach(cb => cb(data));
},
// 新增：取消订阅（避免内存泄漏）
unsubscribe(type, callback) {
if (!this.subscribers[type]) return;
this.subscribers[type] = this.subscribers[type].filter(cb => cb !== callback);
}
};
// 挂载到Vue原型
Vue.prototype.$mediator = mediator;
}
};
然后在main.js里引入：
import Vue from 'vue';
import Mediator from './plugins/mediator';
Vue.use(Mediator);
现在，组件里就可以直接用this.$mediator了。举个电商场景的例子：购物车组件、商品详情组件、导航栏购物车图标的交互。当你在商品详情页点击“加入购物车”，需要：
<!-商品详情组件 >
export default {
methods: {
addToCart() {
const product = { id: 1, name: 'iPhone', price: 5999 };
// 发布"addCart"消息，传递商品信息
this.$mediator.publish('addCart', product);
}
}
};
<!-
购物车组件 >
export default {
mounted() {
// 订阅"addCart"消息，更新购物车列表
this.$mediator.subscribe('addCart', (product) => {
this.cartList.push(product);
this.updateTotalPrice();
});
},
beforeDestroy() {
// 离开页面时取消订阅，避免内存泄漏
this.$mediator.unsubscribe('addCart', this.handleAddCart);
}
};
<!-
导航栏组件 >
export default {
mounted() {
// 订阅"addCart"消息，显示小红点
this.$mediator.subscribe('addCart', () => {
this.showBadge = true;
});
}
};
你发现没？商品详情组件完全不用关心“购物车怎么更新”“小红点怎么显示”，它只需要告诉中介者“我加了个商品”，剩下的交给其他组件自己处理。这种方式比“详情组件直接调用购物车组件的add方法”灵活多了——如果以后要加“加入购物车后发送优惠券”的功能，只需要新增一个订阅“addCart”消息的组件，完全不用改详情组件的代码。这就是“开放封闭原则”的体现：对扩展开放，对修改封闭。
React项目实战：用Hook封装中介者，更符合函数式编程
React项目里没有Vue的原型挂载，不过我们可以用自定义Hook来封装中介者，用起来更符合React的函数式风格。我在React项目里常用的方式是创建一个useMediator.js Hook，结合useEffect来处理订阅和取消订阅。
先创建中介者核心逻辑：
// src/hooks/mediatorCore.js
const mediator = {
subscribers: {},
subscribe(type, callback) {
if (!this.subscribers[type]) this.subscribers[type] = new Set();
this.subscribers[type].add(callback);
},
publish(type, data) {
if (!this.subscribers[type]) return;
this.subscribers[type].forEach(callback => callback(data));
},
unsubscribe(type, callback) {
if (!this.subscribers[type]) return;
this.subscribers[type].delete(callback);
}
};
export default mediator;
然后创建自定义Hook：
// src/hooks/useMediator.js
import { useEffect } from 'react';
import mediator from './mediatorCore';
export default function useMediator(type, callback) {
useEffect(() => {
mediator.subscribe(type, callback);
// 组件卸载时取消订阅
return () => {
mediator.unsubscribe(type, callback);
};
}, [type, callback]);
return {
publish: (data) => mediator.publish(type, data)
};
}
这样，在组件里用起来就很简单了。比如一个“评论组件”和“点赞组件”，评论提交后要通知点赞组件重置点赞状态：
// 评论组件
function CommentComponent() {
const { publish } = useMediator('commentSubmitted');
const handleSubmit = () => {
// 提交评论逻辑...
publish({ commentId: '123', content: '中介者模式真好用！' });
};
return ;
}
// 点赞组件
function LikeComponent() {
const [likeCount, setLikeCount] = useState(0);
useMediator('commentSubmitted', () => {
// 评论提交后重置点赞数
setLikeCount(0);
});
return
点赞数：{likeCount};
}
这个Hook帮我们自动处理了“组件挂载时订阅，卸载时取消订阅”的逻辑，避免了手动管理生命周期的麻烦。我之前在一个React博客项目里用这种方式，实现了“侧边栏目录”“正文内容”“返回顶部按钮”的联动——滚动正文时，中介者通知目录高亮当前章节，同时告诉返回顶部按钮是否显示；点击目录时，中介者通知正文滚动到对应位置。整个交互逻辑拆解得非常清晰，后来产品加了个“夜间模式切换”，只需要新增一个订阅“themeChange”消息的组件，5分钟就搞定了。
中介者模式vs其他模式：到底该选哪个？一张表格帮你理清
很多人会把中介者模式和观察者模式、状态管理库搞混，其实它们各有适用场景。我整理了一张对比表，你可以根据项目需求选择：
你要是问我中介者模式和Vuex/Pinia的区别，我给你打个比方吧——中介者模式就像你小区里那个只负责传话的保安大爷，谁家有快递到了、谁家水管坏了，大爷帮着喊一嗓子，具体取快递、修水管的事儿还是得自己来；而Vuex/Pinia呢，更像是小区的物业办公室，不仅管传话，还得记着每家每户的物业费交没交、停车位是谁的，是个“管事儿的”。
中介者模式管的是“临时搭伙”的事儿。你想啊，你做个表单页面，里面有姓名输入框、手机号输入框、验证码按钮，这仨组件得互相配合——手机号没填对，验证码按钮就不能点；验证码填完了，提交按钮才能亮。这种时候用中介者就特合适，三个组件不用互相盯着对方，都告诉中介者“我现在啥状态”，中介者再通知相关的组件“该变状态了”，干完这票表单提交，这仨组件可能就各回各家了，下次再用也还是这套逻辑。
但Vuex/Pinia不一样，它们管的是“全家桶”的事儿。比如你项目里的用户登录信息，首页要显示头像昵称、购物车要判断用户有没有登录、个人中心要加载用户订单，这些数据整个项目到处都要用，总不能每个组件都自己存一份吧？这时候就该Vuex/Pinia出场了，把用户信息存到“全局仓库”里，哪个组件要用就去仓库里取，改的时候也统一改仓库，省得数据乱套。
我实际做项目的时候，一般是俩搭配着用。比如做电商APP，用户信息、购物车列表这种“全APP都要用”的数据，肯定放Pinia里；但购物车页面里的“数量加减按钮”和“价格显示”这俩组件的联动，就用中介者模式——按钮点一下告诉中介者“数量变了”，中介者通知价格显示“该重新算钱了”，这样代码清爽，也不用把数量这种临时数据塞到全局仓库里占地方。
中介者模式和Vuex/Pinia有什么区别？
你可以把中介者模式理解为“轻量级通信管家”，而Vuex/Pinia是“全家桶状态仓库”。中介者模式更关注“组件间的临时交互逻辑”，比如两个非父子组件的弹窗联动、表单元素间的状态同步，不需要定义复杂的state和mutation；而状态管理库适合管理“全局共享状态”，比如用户信息、购物车数据，需要严格的状态更新规则。简单说，中介者解决“局部通信乱”，状态管理库解决“全局数据散”，实际项目里两者可以搭配用——全局状态放Vuex，组件临时交互用中介者。
什么时候不适合用中介者模式？
如果你的项目只有2-3个组件，或者组件间通信很简单（比如父子组件传值），就没必要用中介者模式。比如一个页面只有“搜索框”和“结果列表”，直接用props+emit传值就行，强行加中介者反而多此一举。 如果组件通信逻辑特别简单（比如点击按钮显示弹窗），用事件总线（EventBus）或原生事件监听也足够，中介者模式更适合“多组件复杂依赖”的场景，比如5个以上组件需要互相传递状态时。
中介者模式会让代码变复杂吗？
这取决于你怎么设计中介者。如果把所有组件的交互逻辑都堆到一个中介者里，确实会变成“大杂烩”，反而难维护；但如果中介者只负责“转发消息”，不处理具体业务逻辑（比如计算价格、调用接口），就不会复杂。我通常会在中介者里只写“谁发消息、发给谁”的规则，具体处理逻辑还是放在组件里。比如购物车中介者只负责“商品添加后通知列表更新”，而计算总价的逻辑仍在购物车组件内，这样中介者代码会很清爽。
如何避免中介者变成“上帝对象”？
“上帝对象”就是中介者包揽所有逻辑，最后变得臃肿难维护。避免这个问题有个小技巧：按“业务场景拆分中介者”。比如电商项目可以拆成“购物车中介者”“订单中介者”“用户中介者”，每个中介者只管一块功能。我之前做过一个后台系统，把中介者按页面拆成“数据表格中介者”“表单中介者”，各自处理表格筛选/分页、表单验证/提交的通信，就算某个中介者出问题，也不会影响其他模块。
新手如何快速在项目中实践中介者模式？
你从“两个组件的简单通信”开始练手。比如你项目里有“筛选条件组件”和“数据表格组件”，以前是筛选组件直接调用表格组件的refresh()方法，现在改成：筛选组件告诉中介者“筛选条件变了”，中介者再通知表格组件“该刷新数据了”。先用这种小场景练手，熟悉订阅/发布的逻辑，再逐步扩展到多组件场景。我带实习生时，都是让他们先改这种“两个组件互调”的代码，一般2-3个场景练下来，就能掌握中介者模式的核心思路了。
