发布/订阅模式在状态管理中是什么，以及它的权衡是什么？

Question

Accepted Answer

**发布/订阅 (pub/sub)** 是一种消息传递模式，其中 **发布者** 发出事件，**订阅者** 对其做出反应，彼此之间不直接了解。许多状态库（和事件系统）都是在此基础上构建的——存储 *发布* 变化，组件 *订阅* 这些变化。

## 最小化的 pub/sub 存储

```js
function createStore(initial) {
  let state = initial;
  const subscribers = new Set();

return {
    getState: () => state,
    setState(next) {
      state = { ...state, ...next };
      subscribers.forEach((fn) => fn(state)); // PUBLISH: notify all subscribers
    },
    subscribe(fn) {
      subscribers.add(fn);                     // SUBSCRIBE
      return () => subscribers.delete(fn);      // return an unsubscribe function
    },
  };
}
```

组件调用 `subscribe(callback)` 以获得通知；当状态变化时（`setState`），存储会调用每个订阅者。这本质上就是 Redux 的 `store.subscribe`、Zustand 和事件发射器在底层的工作原理。

## 解耦的优势

```text
Publisher (the store) doesn't know WHO is listening.
Subscribers don't know WHO published.
→ They're decoupled, communicating only through the event/store.
```

这种松散耦合让应用程序中不相关的部分可以对相同的变化做出反应，而无需彼此直接引用——灵活且可扩展。

## 权衡

```text
✓ Pros: decoupled, flexible, many-to-many communication, easy to add listeners
✗ Cons:
  - Implicit flow — hard to trace WHO reacts to an event (vs explicit calls)
  - Memory leaks — forgetting to UNSUBSCRIBE keeps dead listeners alive
  - Debugging — indirection makes "why did this run?" harder to answer
  - Ordering — subscriber execution order can be non-obvious
```

最大的实际危险是 **忘记取消订阅**（例如在组件卸载时），这会导致内存泄漏，并且回调可能在已死亡的组件上触发。

```jsx
useEffect(() => {
  const unsub = store.subscribe(handleChange);
  return unsub; // ✅ cleanup — unsubscribe on unmount
}, []);
```

## 为什么这很重要

Pub/sub 是 **大多数状态库和事件系统的底层机制** ——理解它可以解释存储如何通知组件以及 `subscribe`/`unsubscribe` 如何工作。

它解释了这种模式的优点（解耦、灵活的通信）和缺点（隐式数据流难以追踪，以及未清理订阅导致的内存泄漏）。

识别 pub/sub 有助于你理解底层的反应性，并强调始终清理订阅的重要性。