观察者模式的核心在于主题直接管理并通知观察者，而发布订阅模式通过事件中心解耦发布者与订阅者；在javascript中，该模式广泛应用于dom事件、状态管理、实时数据更新等场景，其实现需注意内存泄漏、通知性能、错误处理及数据传递方式，确保系统解耦性与健壮性。
JavaScript中实现观察者模式，核心在于构建一个“主题”（Subject）对象，它负责维护一个订阅者（Observer）列表，并在自身状态发生变化时，遍历这个列表并通知所有已注册的订阅者。说白了，就是让感兴趣的对象（观察者）去“监听”另一个对象（主题）的变化，一旦有变动，主题就会告诉它们。
class Subject { constructor() { this.observers = []; // 存储所有观察者 } /** * 添加一个观察者 * @param {Function} observer - 观察者函数或对象，通常是一个回调函数 */ addObserver(observer) { if (typeof observer === 'function' && !this.observers.includes(observer)) { this.observers.push(observer); } else { // 我个人觉得，这里加个简单的错误提示或者日志会更好， // 毕竟有时候传入的可能不是函数，或者重复添加了 console.warn('Observer must be a unique function.'); } } /** * 移除一个观察者 * @param {Function} observer - 要移除的观察者 */ removeObserver(observer) { this.observers = this.observers.filter(obs => obs !== observer); } /** * 通知所有观察者状态已更新 * @param {*} data - 传递给观察者的数据 */ notify(data) { // 有时候我会考虑是否要异步通知，避免一个耗时观察者阻塞其他， // 但对于多数前端场景，同步通知也挺常见。 this.observers.forEach(observer => { try { observer(data); } catch (error) { // 这里捕获一下观察者执行时的错误，避免一个观察者出错导致整个通知链中断 console.error('Error notifying observer:', error); } }); }}// 示例用法：const mySubject = new Subject();// 定义一些观察者const observerA = (data) => { console.log('观察者A收到通知:', data);};const observerB = (data) => { console.log('观察者B收到通知，数据是:', data);};const observerC = (data) => { console.log('观察者C处理数据:', JSON.stringify(data));};// 注册观察者mySubject.addObserver(observerA);mySubject.addObserver(observerB);mySubject.addObserver(observerC);console.log('--- 第一次状态变化 ---');mySubject.notify({ message: 'Hello from Subject!', timestamp: Date.now() });// 移除一个观察者mySubject.removeObserver(observerB);console.log('--- 第二次状态变化（B已移除）---');mySubject.notify('新的消息');// 尝试添加一个非函数或重复的mySubject.addObserver({}); // 会有警告mySubject.addObserver(observerA); // 不会重复添加
观察者模式与发布订阅模式有何不同？
这真的是一个老生常谈的问题，但它确实很重要，因为两者概念上很接近，但在实现和职责划分上有所区别。在我看来，最核心的区别在于它们之间是否存在一个“中间人”。观察者模式中，主题（Subject）是直接知道并管理着所有观察者（Observer）的。它维护一个观察者列表，并在状态改变时直接调用这些观察者的方法。这是一种“一对多”的直接依赖关系。就像一个明星（主题）直接管理着他的粉丝俱乐部（观察者），有新动态就直接发给所有粉丝。
而发布订阅模式（Pub/Sub）则引入了一个“事件中心”或“消息代理”（Broker/Event Bus）。发布者（Publisher）不直接知道订阅者（Subscriber），它只负责向事件中心发布消息；订阅者也不直接知道发布者，它只向事件中心订阅感兴趣的消息。所有的通信都通过这个中间人来完成。这就像出版社（发布者）把书交给书店（事件中心），读者（订阅者）去书店买书，出版社和读者之间并不直接打交道。
从解耦程度上看，发布订阅模式的解耦更彻底，因为它消除了发布者和订阅者之间的直接依赖。主题（发布者）和观察者（订阅者）之间完全互不干涉。这在大型应用中特别有用，可以避免组件之间形成复杂的网状依赖。观察者模式虽然也实现了观察者和主题的解耦（观察者不需要知道主题的具体实现，只需要知道它有
notify
方法），但主题本身还是需要管理观察者的列表，这种耦合是存在的。所以，选择哪种模式，往往取决于你对系统解耦程度的需求以及复杂性考量。
在哪些实际场景中，观察者模式能发挥作用？
观察者模式在前端开发中简直是无处不在，只是我们可能不总用“观察者模式”这个词来称呼它。最直观的例子就是DOM事件处理。当你在一个按钮上添加
addEventListener
监听点击事件时，这个按钮就是主题，你的回调函数就是观察者。按钮被点击时，它会通知所有注册的监听器。这不就是典型的观察者模式吗？
再比如，单页应用中的状态管理。虽然像Redux这样的库更多地被认为是发布订阅模式（因为它有一个中央的store作为事件中心），但其内部某些机制，比如组件订阅store的变化，然后根据变化重新渲染，这本质上也是一种观察行为。如果你自己实现一个简单的全局状态管理器，让组件注册监听某个状态的变化，那这就是观察者模式的典型应用。
千帆大模型平台
面向企业开发者的一站式大模型开发及服务运行平台
0 查看详情
还有一些场景，比如：
实时数据更新： 假设你有一个图表组件，需要实时展示后端推送的数据。后端数据一更新，主题（数据服务）就通知图表组件（观察者）去刷新。UI组件间的通信： 当一个表单输入框的值改变时，可能需要另一个显示区域同步更新。输入框作为主题，显示区域作为观察者。游戏开发： 玩家角色的生命值、分数等属性变化时，可以通知UI显示、音效播放等观察者。
我觉得，只要是涉及到“当A发生变化时，B、C、D需要做出响应”这种需求，观察者模式就值得考虑。它提供了一种清晰、可维护的方式来处理这种一对多的依赖关系。
实现观察者模式时，有哪些常见的陷阱或优化考量？
实现观察者模式，虽然概念上简单，但在实际应用中还是有些细节需要注意，不然可能会引入一些问题。
一个比较常见的陷阱是内存泄漏。如果观察者没有被正确地从主题中移除，即使观察者本身已经不再被使用了（比如对应的DOM元素被移除了），主题仍然会持有对它的引用。这意味着垃圾回收器无法回收这个观察者，导致内存占用持续增加。这在单页应用中尤其常见，页面切换或者组件销毁时，忘记取消订阅是很要命的。所以，我的经验是，在组件生命周期结束时（比如React的
componentWillUnmount
或
useEffect
的返回函数中），一定要记得调用
removeObserver
。
另一个是通知的顺序和性能。如果有很多观察者，或者某个观察者的回调函数执行时间很长，同步通知可能会阻塞主线程，导致UI卡顿。这时可以考虑异步通知，比如使用
setTimeout
、
requestAnimationFrame
或者微任务（
Promise.resolve().then(...)
）来调度观察者的执行。这样可以把耗时操作放到事件循环的下一轮，避免阻塞。但异步通知也会带来额外的复杂性，比如如何确保通知的顺序，以及如何处理通知失败的情况。
再来就是错误处理。在我的示例代码里，我加了一个
try-catch
块来包裹观察者的执行。这是很重要的，因为如果一个观察者在执行时抛出了未捕获的错误，它可能会中断整个通知链，导致后续的观察者无法收到通知。捕获错误并记录下来，可以确保系统的健壮性。
最后，还有参数传递的考量。
notify
方法通常会传递一些数据给观察者。这些数据应该包含观察者所需的所有信息，但也要避免传递过大的对象，否则会增加内存开销和数据序列化的负担。有时候，一个简单的ID或者一个表示变化类型的枚举值就足够了，观察者可以根据这个ID再去主题那里拉取更详细的数据。这种“拉取”模式（Pull Model）与“推送”模式（Push Model）是观察者模式的两种变体，各有优缺点。推送模式简单直接，但可能传递冗余数据；拉取模式更灵活，但观察者需要主动获取数据。具体用哪种，得看实际需求。
以上就是JS如何实现观察者模式的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/339265.html
微信扫一扫 
支付宝扫一扫 
