发布订阅模式通过事件总线实现组件间解耦，核心是发布者与订阅者不直接通信，而是通过中心化的调度器传递消息，提升代码模块化与可维护性。
JavaScript中实现发布订阅（Publish-Subscribe）模式，或者说事件总线（Event Bus），核心在于构建一个中心化的调度器。这个调度器不直接连接消息的发送方和接收方，而是作为中间人，让发送方（发布者）只管把消息扔给它，接收方（订阅者）只管告诉它自己对什么消息感兴趣。这样，两者之间就没有直接的依赖关系，实现了彻底的解耦。
发布订阅模式的实现，通常会围绕一个中心对象来构建。这个对象内部维护一个映射表，键是事件名称，值是所有对该事件感兴趣的回调函数列表。
class EventBus {
constructor() {
// 存储所有事件及其对应的回调函数
// 结构大概是: { 'eventName': [callback1, callback2], 'anotherEvent': [callback3] }
this.events = {};
}
/**
* 订阅事件
* @param {string} eventName - 事件名称
* @param {function} callback - 事件触发时执行的回调函数
* @returns {function} 一个用于取消订阅的函数，方便链式调用或在特定时机取消
*/
subscribe(eventName, callback) {
if (!this.events[eventName]) {
this.events[eventName] = [];
}
this.events[eventName].push(callback);
// 返回一个取消订阅的函数，这样使用者就不需要手动调用unsubscribe并传入callback
return () => {
this.unsubscribe(eventName, callback);
};
}
/**
* 发布事件
* @param {string} eventName - 要发布的事件名称
* @param {*} data - 传递给订阅者的任意数据
*/
publish(eventName, data) {
if (this.events[eventName]) {
// 遍历所有订阅了该事件的回调函数并执行
// 这里加个try-catch，防止某个回调函数出错影响其他回调的执行
this.events[eventName].forEach(callback => {
try {
callback(data);
} catch (e) {
console.error(`Error in callback for event "${eventName}":`, e);
}
});
}
}
/**
* 取消订阅
* @param {string} eventName - 事件名称
* @param {function} callback - 要取消的回调函数
*/
unsubscribe(eventName, callback) {
if (this.events[eventName]) {
this.events[eventName] = this.events[eventName].filter(cb => cb !== callback);
}
}
/**
* 清除某个事件的所有订阅
* @param {string} eventName - 事件名称
*/
clear(eventName) {
if (this.events[eventName]) {
delete this.events[eventName];
}
}
/**
* 清除所有事件的所有订阅（慎用）
*/
clearAll() {
this.events = {};
}
}
// 使用示例：
const eventBus = new EventBus();
// 组件A订阅 'userLoggedIn' 事件
const unsubscribeA = eventBus.subscribe('userLoggedIn', (user) => {
console.log(`Component A: User ${user.name} logged in!`);
});
// 组件B订阅 'userLoggedIn' 事件，并且只对特定用户感兴趣
const unsubscribeB = eventBus.subscribe('userLoggedIn', (user) => {
if (user.id === 123) {
console.log(`Component B: Special user ${user.name} (ID: ${user.id}) detected.`);
}
});
// 组件C订阅 'itemAddedToCart' 事件
eventBus.subscribe('itemAddedToCart', (item) => {
console.log(`Component C: Added ${item.name} to cart. Quantity: ${item.quantity}`);
});
// 模拟用户登录
console.log('\n--- Publishing userLoggedIn event ---');
eventBus.publish('userLoggedIn', { id: 123, name: 'Alice' });
eventBus.publish('userLoggedIn', { id: 456, name: 'Bob' });
// 模拟商品加入购物车
console.log('\n--- Publishing itemAddedToCart event ---');
eventBus.publish('itemAddedToCart', { id: 'prod001', name: 'Laptop', quantity: 1 });
// 组件A不再关心用户登录事件
console.log('\n--- Component A unsubscribes ---');
unsubscribeA(); // 调用之前subscribe返回的取消函数
// 再次模拟用户登录，Component A将不再收到通知
console.log('\n--- Publishing userLoggedIn again after unsubscribe ---');
eventBus.publish('userLoggedIn', { id: 789, name: 'Charlie' });
// 清除Component B的订阅
unsubscribeB();
console.log('\n--- Publishing userLoggedIn after B unsubscribes ---');
eventBus.publish('userLoggedIn', { id: 123, name: 'David' }); // 此时没有任何订阅者了JS发布订阅模式解决了哪些痛点？
在我看来，发布订阅模式最核心的价值在于它带来的“解耦”。在复杂的JavaScript应用，特别是前端单页应用中，组件间的通信常常是个令人头疼的问题。想象一下，一个用户登录组件需要通知页面头部显示用户信息，同时还要通知购物车组件更新商品数量，甚至可能还要通知某个分析服务记录登录事件。如果这些组件之间都直接相互调用，那代码会变得非常脆弱和难以维护。任何一个组件的改动都可能牵一发而动全身，导致大量的回归测试。
发布订阅模式就像一个消息中心，登录组件只需要把“用户已登录”这个事件发布出去，它根本不需要知道谁会关心这个事件。而页面头部、购物车、分析服务等，它们只需要订阅自己感兴趣的事件。这样一来，组件之间不再有直接的依赖，它们只依赖于这个事件总线。这极大地提升了代码的模块化和可维护性。我个人觉得，当你发现两个看似不相关的模块或组件，却因为某个操作必须直接调用对方的方法时，这往往就是发布订阅模式登场的最佳时机。它让你的系统变得更加灵活，更容易扩展。
发布订阅模式与观察者模式有何不同？
这是一个经典的面试题，也常常让人混淆。虽然它们都与事件和通知有关，但核心的区别在于是否存在一个“中间人”。
观察者模式（Observer Pattern）： 它是一种“一对多”的依赖关系。主体（Subject）直接维护一个观察者（Observer）列表，当主体状态发生变化时，它会直接通知所有注册的观察者。你可以把它想象成报社（主体）直接知道所有订阅报纸的读者（观察者）的地址，报纸一印出来，报社就直接派人把报纸送到每个读者手里。这里的关键是，主体直接知道并管理着它的观察者。比如，DOM事件监听（
addEventListener）就是观察者模式的典型应用：DOM元素是主体，你添加的事件回调函数是观察者，DOM元素状态改变（如点击）时，它直接调用你的回调。
发布订阅模式（Publish-Subscribe Pattern）： 它引入了一个中间层，也就是我们说的“事件总线”或“消息代理（Broker）”。发布者（Publisher）不直接与订阅者（Subscriber）通信，它只是把消息发布到事件总线。订阅者也不直接知道发布者是谁，它只是向事件总线订阅自己感兴趣的事件。事件总线负责接收发布者的消息，并转发给所有订阅了该消息的订阅者。这就像报社（发布者）把新闻稿发给一个新闻分发中心（事件总线），然后分发中心再把新闻发给全国各地的报摊（订阅者）。报社不需要知道每个报摊的具体位置，报摊也不需要知道新闻稿是哪个报社发的。
我的理解是：观察者模式是一种紧耦合的实现，主体和观察者之间是直接关联的。而发布订阅模式则通过引入一个独立的事件总线，实现了发布者和订阅者之间的彻底解耦，它们互不感知对方的存在，只与事件总线打交道。这种解耦在大型应用中尤其重要，它能有效降低模块间的耦合度，提升系统的可扩展性和可维护性。
使用事件总线时需要注意哪些陷阱？
事件总线虽然强大，但使用不当也可能引入新的问题。我个人在项目里就踩过不少坑：
一个比较常见的问题是内存泄漏。在单页应用中，组件的生命周期管理至关重要。如果你在一个组件挂载时订阅了事件，但在组件销毁时忘记取消订阅（
unsubscribe），那么即使组件DOM被移除，它的回调函数仍然可能被事件总线持有，导致该组件的内存无法被垃圾回收。随着时间的推移，这会累积大量的“幽灵”回调，最终拖垮应用性能。所以，每次订阅都记得在合适的时机（比如React的
useEffect的清理函数，Vue的
onUnmounted）进行取消订阅操作，是至关重要的好习惯。
其次，调试困难也是一个令人头疼的问题。当你的应用变得庞大，事件流复杂起来时，一个事件被发布后，可能会触发多个订阅者，而这些订阅者又可能发布新的事件，形成一个复杂的事件链。如果事件命名不规范，或者事件参数结构不清晰，当出现问题时，你很难追踪事件的源头、路径以及为什么某个回调没有被触发，或者被不该触发的回调触发了。我曾经为了排查一个奇怪的bug，不得不给每个事件发布和订阅的地方都加上大量的
console.log，才勉强摸清了事件的流向。因此，清晰的事件命名约定、规范的事件数据结构，以及适当的日志记录，都显得尤为重要。
再来，事件滥用也是一个隐患。并不是所有的组件通信都需要通过事件总线。有时候，简单的父子组件通过props传递数据和回调，或者兄弟组件通过共同的父组件进行状态提升，会比引入事件总线更加直观和高效。过度使用事件总线，反而可能让你的代码逻辑变得过于分散和隐晦，降低可读性。当你发现一个简单的功能需要发布好几个事件才能完成时，也许就该停下来思考一下，是不是过度设计了。事件总线是解决复杂通信的利器，但也要避免把它变成“万能钥匙”，无差别地应用到所有场景。
