JS如何实现观察者模式

观察者模式的核心在于主题直接管理并通知观察者，而发布订阅模式通过事件中心解耦发布者与订阅者；在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的变化，然后根据变化重新渲染，这本质上也是一种观察行为。如果你自己实现一个简单的全局状态管理器，让组件注册监听某个状态的变化，那这就是观察者模式的典型应用。

DreamStudio

SD兄弟产品！AI 图像生成器

下载

还有一些场景，比如：

• 实时数据更新： 假设你有一个图表组件，需要实时展示后端推送的数据。后端数据一更新，主题（数据服务）就通知图表组件（观察者）去刷新。
• UI组件间的通信： 当一个表单输入框的值改变时，可能需要另一个显示区域同步更新。输入框作为主题，显示区域作为观察者。
• 游戏开发： 玩家角色的生命值、分数等属性变化时，可以通知UI显示、音效播放等观察者。

我觉得，只要是涉及到“当A发生变化时，B、C、D需要做出响应”这种需求，观察者模式就值得考虑。它提供了一种清晰、可维护的方式来处理这种一对多的依赖关系。

实现观察者模式时，有哪些常见的陷阱或优化考量？

实现观察者模式，虽然概念上简单，但在实际应用中还是有些细节需要注意，不然可能会引入一些问题。

一个比较常见的陷阱是内存泄漏。如果观察者没有被正确地从主题中移除，即使观察者本身已经不再被使用了（比如对应的DOM元素被移除了），主题仍然会持有对它的引用。这意味着垃圾回收器无法回收这个观察者，导致内存占用持续增加。这在单页应用中尤其常见，页面切换或者组件销毁时，忘记取消订阅是很要命的。所以，我的经验是，在组件生命周期结束时（比如React的

componentWillUnmount

useEffect

removeObserver

另一个是通知的顺序和性能。如果有很多观察者，或者某个观察者的回调函数执行时间很长，同步通知可能会阻塞主线程，导致UI卡顿。这时可以考虑异步通知，比如使用

setTimeout

requestAnimationFrame

Promise.resolve().then(...)

再来就是错误处理。在我的示例代码里，我加了一个

try-catch

最后，还有参数传递的考量。

notify