手写200行rea响应式事件聚合器：Proxy、事件总线与中间件设计

1. 为什么会有 rea：一次事件总线改造踩出的需求

1.1 从组件 props 连环传参说起

rea 这个项目，名字全称是 Reactive Event Aggregator，翻译过来叫"响应式事件聚合器"。但它并不是我一开始就规划好的框架级东西，纯粹是业务代码被逼出来的。当时我在维护一个某公司的中后台项目，页面不算多，但交叉业务特别重，最典型的场景是：用户在一个列表页点击"编辑"，弹出抽屉，抽屉里改了数据，左侧统计卡片要立刻刷新，右上角操作日志要追加一条，底部导航还要点亮未读标记。

这种跨模块联动，如果老老实实按组件树一层层传 props，会写成什么样子？数据从抽屉传到父页面，父页面再派发给统计卡片和日志组件，中间但凡多一层路由缓存或者 keep-alive，整个链路就断了。我一开始图省事，直接在 window 上挂了一个事件总线，结果用了一两周就发现问题：全局事件名完全没有约束，A 模块 emit 的user:update和 B 模块监听的user-update是两码事，排查问题时只能全局搜字符串，事件一多连谁触发谁都理不清。

1.2 现成状态库为什么没被采用

项目组其实也讨论过要不要直接上大型状态管理库。后来没采用，理由很实际：一是这类库的学习曲线对团队里新来的同学不太友好，概念名词一堆，光是理解 action、reducer、mutation、getter 这些术语就要花掉一两天；二是我们很多页面是渐进式改造的，不可能为一个模块重写整个数据流；三是项目本身没有 SSR、没有复杂服务端渲染需求，重型方案带来的性能收益根本用不上。

我想要的东西其实特别朴素：一个全局的内存数据仓库，数据变了能自动通知相关模块；有一套清晰的事件机制，能让模块之间发消息；还要支持在数据流里插入日志、持久化这类横切逻辑。最重要的是，整个库的代码量要小到我能看懂每一行，出了问题能自己改，而不是去翻一个几万行的源码仓库。rea 就是按照这个标准慢慢磨出来的。

1.3 rea 的定位与命名由来

rea 的核心定位可以概括成一句话：一个适合中小型项目、看得懂每一行源码的响应式状态容器。它不算革命性创新，底层就是 Proxy 加发布订阅，再加一层中间件管道。之所以叫"聚合器"，是因为它把两件事聚合到了一起：一是把普通对象变成响应式数据，二是把模块间通信统一成命名空间事件。这两件事过去往往要引入两个独立库，rea 用一套 API 把它们收拢了。

我当时给自己定的目标也很具体：核心代码控制在 200 行左右，不依赖任何第三方包，浏览器和 Node 环境都能跑。这个目标逼着我砍掉了很多花哨功能，比如时间旅行、持久化快照这些，最后留下来的都是每天写业务真正用得到的东西。下面我会把设计思路、核心实现和踩过的坑完整展开，如果你也在为项目里分散的全局状态头疼，或者想理解响应式状态管理最底层的原理，这篇应该能给你一个可以直接照抄的答案。

2. rea 的三种核心机制：响应式数据、事件总线、中间件管道

2.1 响应式数据的底层：Proxy 拦截与依赖表

先说响应式数据。JavaScript 里把一个普通对象变成"响应式"，最现代的手段就是 Proxy。它的原理理解起来不难：对象上的每一次属性读取和写入，都会先经过get和set陷阱函数，我们可以在陷阱里做手脚——读取时记录"谁在读这个属性"，写入时查出"所有等着这个属性变化的人"，然后挨个通知他们。

这里有一个关键设计：依赖表放在哪里。rea 选择把依赖表存在一个全局的 WeakMap 里，键是目标对象本身，值是一个 Map，Map 里再按属性名分桶，每个桶里放一个订阅者集合。用 WeakMap 而不是普通 Map，是防止对象被回收时依赖表还强引用着它，造成内存泄漏。这是很容易被忽略的细节，很多初学响应式原理的人都会栽在这里。

写入侧的流程则是反过来的：set陷阱里先判断新值和旧值是否相同，相同就直接返回true，不做任何通知；不同才更新值，然后从依赖表里去取这个属性的订阅者集合，逐个执行回调。为什么先比较再通知？这能挡掉大量无意义的重复赋值，尤其在 React 这类框架里，父组件一旦重渲染，子组件的props赋值经常会传进同一个引用，不做比较就会引发无谓的订阅者执行。

2.2 事件总线的设计：命名空间与生命周期钩子

光有响应式数据还不够，模块之间有些消息并不是简单的"字段变了"，比如"用户点击了刷新按钮""导入任务完成了第一步"，这些语义化事件没法用"属性赋值"来表达。所以 rea 里还内置了一个事件总线，API 参考了 Node 的 EventEmitter，但做了两个调整。

第一个调整是强制使用命名空间。事件名必须是模块名:动作名的形式，比如order:created、user:logout。我用一个小工具函数在注册时检查事件名格式，不合法直接抛错。这看起来是限制，实际用起来反而省心——全局搜order:created就能把所有触发方和订阅方一次性找出来，重构时不用猜。

第二个调整是给事件总线加上了生命周期钩子。每个模块可以注册onMount和onDestroy钩子，分别在模块首次创建和销毁时被调用。这么做的好处是把"订阅事件"和"解除订阅"这两件事收口了：模块在onMount里订阅，在onDestroy里自动清理，不会出现订阅了忘了解除的漏网之鱼。这一点在单页应用里特别重要，页面切换时旧页面的回调还在响应全局事件，是经典的内存泄漏和诡异 Bug 源头。

2.3 中间件为什么放在派发链路上

中间件这个概念在 Express 和 Koa 里很常见，rea 把它用在了数据派发链路上。你可能要问：一个浏览器里跑的小状态库，要中间件干什么？

我的答案是：日志、持久化、防抖节流、权限过滤这些横切关注点，如果散落在业务代码里，会把这些通用逻辑和具体业务糊成一团。举个例子，表单自动保存功能：数据每次变化都要写入 localStorage，但用户连续打字时写入太频繁会卡，所以要做一个 500ms 的防抖。如果用中间件，我只需要写一个persistMiddleware，放在派发链条的最外层，数据变更事件经过它时先做防抖合并，再落盘。业务组件里依然只做最单纯的store.set('form', newData)，完全不用关心持久化和节流。

中间件在 rea 里的形态是一个函数，签名固定为(context, next) => void。context里携带了变更类型、变更路径、新旧值、触发来源；next是管道里的下一个中间件。中间件可以决定是否放行、修改上下文、提前返回。这个设计我实际用下来觉得是 rea 里性价比最高的部分——核心逻辑 30 行左右，但能解决的问题范围比响应式本身还宽。

3. 手写一个约 200 行的 rea：核心代码逐段拆解

3.1 Store 骨架与 subscribe 接口

先看最外层骨架。rea 对外暴露一个createStore函数，传入初始数据对象，返回一个带get、set、subscribe和emit方法的实例：

function createStore(initialState) { const state = reactive(initialState); const events = new Map(); // 事件名 -> Set<回调> return { get(path) { return getByPath(state, path); }, set(path, value) { state = setByPath(state, path, value); }, subscribe(path, fn) { return watch(state, path, fn); }, emit(eventName, payload) { if (!events.has(eventName)) return; events.get(eventName).forEach((fn) => fn(payload)); }, on(eventName, fn) { if (!/^[a-zA-Z0-9_-]+:[a-zA-Z0-9_-]+$/.test(eventName)) { throw new Error(`[rea] 非法事件名: ${eventName}`); } if (!events.has(eventName)) events.set(eventName, new Set()); events.get(eventName).add(fn); return () => events.get(eventName).delete(fn); }, }; }

get(path)和set(path, value)里的 path 用的是点路径字符串，比如'user.profile.name'。为什么要设计成字符串路径而不是直接传对象？因为中间件和日志系统需要知道"到底改了哪个字段"，如果只存一个整对象引用，每次变化都得深比较才能算出差异，成本太高。点路径让每次变更都自带"坐标"，日志、撤销、权限校验全都可以基于这个坐标做文章。

set方法这里我写的是简化版，真正的 rea 内部会先对 path 做解析，再递归找到父节点，最后在叶子节点上触发 Proxy 的赋值逻辑，从而自动唤起该路径的订阅者。这就是下一节要讲的核心。

3.2 递归响应式代理的实现

响应式核心用 Proxy 实现，关键是递归代理。直接对初始对象做一次new Proxy(initialState)是不够的，因为用户如果改的是嵌套子对象里的属性，比如set('user.profile.name', '张三')，外层 Proxy 的set陷阱根本不会触发——JavaScript 的 Proxy 默认不感知嵌套结构。

正确的做法是在get陷阱里做懒代理：读取某个属性时，如果发现值是一个非空对象并且还没被代理过，就立即给它包一层新的 Proxy 缓存起来。这样就能保证无论嵌套多深，只要在读取链路中经过的属性，都会被代理覆盖。代码大致长这样：

function reactive(target, path = '', cache = new WeakMap()) { if (target === null || typeof target !== 'object') return target; if (cache.has(target)) return cache.get(target); const proxy = new Proxy(target, { get(obj, key) { const value = Reflect.get(obj, key); // 关键：读取嵌套对象时先递归代理 return reactive(value, path ? `${path}.${key}` : key, cache); }, set(obj, key, newValue) { const oldValue = Reflect.get(obj, key); if (oldValue === newValue) return true; const nextPath = path ? `${path}.${key}` : `${key}`; Reflect.set(obj, key, newValue); trigger(nextPath, newValue, oldValue); return true; }, deleteProperty(obj, key) { const nextPath = path ? `${path}.${key}` : `${key}`; Reflect.deleteProperty(obj, key); trigger(nextPath, undefined, '前端在删除时不传旧值'); return true; }, }); cache.set(target, proxy); return proxy; }

这里cache参数用的是 WeakMap，key 是原始对象，value 是代理对象。它的重要性体现在一个反例里：如果不用缓存，同一个原始对象每次被读取都会生成一个新代理，那么第一次读取时注册的订阅者，和第二次读取时拿到的就不是同一个代理实例，订阅关系全乱了。

trigger(nextPath, newValue, oldValue)要做的事是根据路径去依赖表里找订阅者集合，然后把路径上所有的订阅者都执行一遍，同时把这个变更的完整上下文交给中间件管道，这样中间件才能在数据真正更新前后做横切处理。中间件衔接的代码我放在下一节一起看。

3.3 中间件与 batch 批处理

中间件管道是数据写入的必经之路。每次set被 Proxy 拦截后，不直接触发订阅者，而是先构建一个变更上下文ctx，然后按顺序塞进中间件数组跑一遍。每个中间件签名是(ctx, next) => void，内部通过await next()决定是否放行。注意这是同步为主的场景，所以 rea 的管道用的是一个"倒着循环"的实现，而不是递归：

function compose(middlewares, ctx) { let index = -1; function dispatch(i) { if (i <= index) throw new Error('中间件不能重复执行 next()'); index = i; if (i === middlewares.length) return; const middleware = middlewares[i]; middleware(ctx, () => dispatch(i + 1)); } dispatch(0); }

为什么要限制"不能重复执行 next()"？因为项目里真的遇到过：有人写了个日志中间件，记录变更信息之后又调了一次next()，导致后面的中间件执行了两遍，副作用跟着翻倍。这个限制在 Express 社区是成熟经验，直接搬过来。

批量派发batch是另一个实用功能：连续修改多个字段时，不希望每个字段都立刻触发订阅者，否则表单组件会重复渲染十几次。rea 的解决方案是用一个微任务缓冲：set时先把待通知的订阅者集合合并到一个队列里，然后用queueMicrotask安排一个统一派发。这意味着同步代码里的十次set，最终只会触发一次订阅者回调。代价是订阅者的回调变成了异步执行，好在状态管理场景里几乎没人需要依赖同步通知的时序。

3.4 断点验证：一段可直接跑起来的调用示例

写到这里，代码光说不练不放心。下面是我在开发 rea 时反复用来做冒烟测试的一个示例，你可以直接复制到浏览器控制台跑：

const store = createStore({ user: { name: '张三', settings: { theme: 'dark' } }, cart: [], }); // 订阅 user.settings.theme，打印变更 const unsub = store.subscribe('user.settings.theme', (newVal, oldVal) => { console.log(`主题变更: ${oldVal} -> ${newVal}`); }); store.set('user.settings.theme', 'light'); // 控制台输出: 主题变更: dark -> light unsub(); // 取消订阅后不再响应 store.set('user.settings.theme', 'dark'); // 无输出

这段代码验证了三个点：嵌套代理是否生效（路径user.settings.theme有多层嵌套）、订阅回调是否拿到了新旧值、取消订阅是否有效。如果其中任何一点不成立，整个 rea 的设计都要推翻重来。我当时就是先写了这段最小用例，再倒推实现，比先写完整库再审代码的效率高得多。

4. 在真实业务场景里落地：三个我踩过的典型用法

4.1 登录态跨模块联动：从"到处判断 token"到"一处派发全局响应"

登录态是我遇到的第一个强烈需要这种设计的场景。过去每个模块要判断用户是否登录，都得自己去读 token，一旦登出，所有模块的清理逻辑散落各处，经常出现"这个模块清理了那个模块没清理"的问题。

用 rea 之后，我把登录态建模成auth模块，统一在onMount里订阅auth:logout事件，登出时只需要store.emit('auth:logout', { reason: 'expired' })，所有模块的清理逻辑自动执行。关键收益是：新增一个需要响应登出的模块，只需要在它自己的onMount里加上订阅，核心登出流程一行都不用改。这比"登出时手动调用一串清理函数"的写法好维护太多了。

4.2 复杂表单自动保存：把草稿持久化做成中间件

第二个典型用法是表单自动保存。很多后台系统的表单特别长，用户填到一半可能切走，需要做草稿自动保存。如果用set事件驱动，最直觉的写法是在每个表单组件的change事件里localStorage.setItem，但这样性能和代码整洁度都很差。

rea 的做法是加一个persistMiddleware：拦截所有路径以draft.开头的变更，做一个 500ms 的防抖，然后一次性把整个draft字段序列化进 localStorage。业务组件仍然只是store.set('draft.name', event.target.value)，根本不知道有持久化这件事。这样自动保存就从一个"业务动作"降级成了"数据流的副作用"，职责划分清楚了很多。

这个方案还有一个衍生的好处：刷新页面恢复草稿时，只需要在createStore的初始化阶段读一次 localStorage，合并到初始状态里，整个过程不会经过中间件，也不会产生多余的通知。

4.3 实时消息列表与增量更新

第三个场景是实时消息列表。后台系统的消息中心经常要轮询接口，拿到新消息后往列表头部插一条，同时未读计数加一，还要在浏览器标题上闪烁提示。

用 rea 处理时，我把消息列表和未读数建模成两个关联字段，但故意不让它们合并成一个"大状态"。消息列表字段负责存数组，未读数字段只存一个数字。新消息到达时，先store.set('messages', [newMsg, ...oldMessages])更新列表，再store.set('unreadCount', unreadCount + 1)更新计数。两个订阅者各管各的，列表组件不会因为未读数的变化被重渲染，未读计数组件也不会因为列表数组的变化被重渲染。这个拆分粒度，是我在开发里试错试出来的最佳实践：能拆开的字段就拆开，粒度越小，订阅者误触发的概率越低。

5. 踩坑实录：嵌套代理、订阅泄漏、回调顺序三大坑

5.1 坑一：修改嵌套对象不触发任何通知

这个坑是我第一次写 Proxy 响应式时必然踩到的，特点是你根本意识不到它坏了，因为外层对象的修改一切正常，只有嵌套的深层对象"静默失败"。

具体现象是这样的：对store.set('user.profile.name', '李四')，页面没有任何响应。排查过程我先检查了subscribe是否正确注册，检查了路径是否写错，最后才发现问题出在get陷阱没有做递归代理。前面代码里已经说了解决方案：读取属性时如果是对象就当场包一层 Proxy。这里我再补充一个容易忽略的点：对于数组，push、pop、splice这些方法也要做支持，否则store.set('messages', [...])没问题，但store.get('messages').push(newMsg)这种"改对象本身"的写法会绕过set陷阱。

解决方案其实不复杂，在代理get里针对Array.isArray(value)的路径也走递归代理，再配合set陷阱对 length 变化的兜底处理，就能覆盖大多数数组操作。具体代码我放在 rea 的arrayPatch函数里，核心是重写那些会改变数组长度的方法，让它们执行完后手动触发一次trigger('messages')。

5.2 坑二：订阅者泄漏导致页面越来越卡

第二个坑是内存泄漏，排查起来比第一个隐蔽得多。症状是页面切了几个路由之后越来越卡，打开性能面板一看，内存占用不断上升。

定位过程我是这样走的：先用 Chrome 的 Memory 面板抓了三次堆快照，对比后发现有一个大的 Set 结构持续增长，再结合代码搜索，锁定了events这个 Map 里的订阅者集合。真正的问题出在：某模块的onMount里订阅了store.on('order:created', handler)，但模块销毁时没有任何地方调用返回的取消订阅函数。也就是说，每次进入这个模块，就往全局事件表里塞一个新的 handler，旧的 handler 被闭包绑定了大量 DOM 引用，永远无法被 GC 回收。

后来我在 rea 里做了两手修复：第一，on方法无论如何都返回一个unsubscribe函数，鼓励调用方手动清理；第二，模块注册机制在onDestroy时自动遍历该模块所有已注册事件，统一解除。这个经验也教训了我：任何全局事件绑定都必须成对出现，订阅和退订要写在同一个作用域里，不是"记得清理一下"，而是"设计上强迫你不可能忘"。

5.3 坑三：同一路径的多个订阅者，执行顺序颠倒

第三个坑和顺序有关。我在一次调试中发现，日志里 A 模块的订阅者总是在 B 模块的订阅者之后打印，但我明明是按 A 在 B 之前注册的。我以为 rea 内部用了什么排序逻辑，查源码发现根本没有，后来才意识到是另一套机制在捣乱：中间件管道里有人调了await next()但后续逻辑没控制好，把通知流程异步化了。

具体来说，持久化中间件是异步的，它调用next()之前先await了一轮。这导致trigger在派发时被拆成了两段：前半段同步走完 A 订阅者，然后遇到微任务切换，后半段才轮到 B。虽然最终所有订阅者都会执行，但执行的"连续时刻"不再一致，这会造成一种难以复现的竞争状态。比如说订阅者 A 假设"B 已经处理完了"，实际 B 还没跑。

最后的修复方案是：rea 的 trigger 强制使用同步派发，中间件如果要做耗时操作，只能把结果通过 context 传给订阅者，不允许在派发过程中插入await。这个选择牺牲了一定的灵活度，但换来了"订阅者执行顺序与注册顺序严格一致"的确定性。对状态管理这种基础层来说，确定性比灵活性更重要。

5.4 排查链路复盘：我是怎么一步步定位的

总结一下上面三个坑，我自己沉淀了一套排查响应式状态问题的固定套路，分享给你：

1. 先最小化：写一个纯内存的createStore用例，不接 UI，直接在控制台调用set看订阅者是否触发，把"数据层"和"视图层"分开。
2. 再逐步接中间件：如果核心用例通过，但接上中间件就出错，那就逐个注释掉中间件做二分定位，大概率问题出在next()的重复调用或异步派发上。
3. 最后接视图：如果接上视图才出错，基本可以断定是订阅泄漏或组件生命周期问题，去查onDestroy有没有执行。

这套链路帮我节省了大量时间。你不一定用 rea，但如果你用的是其他状态库，同样可以通过"先数据层后视图层"的隔离法去找问题根源。

6. 进阶优化：把 rea 从"能用"推向"好用"

6.1 用 WeakRef 自动回收失效订阅

基础版 rea 已经能跑业务了，但我后来还做了一些进阶优化，第一个就是自动回收订阅者。前面提到过events用的是Map<string, Set<回调>>，回调一旦注册就永远留在集合里，如果应用没有合适的销毁时机，泄漏风险依旧存在。

一个比较优雅的补充是通过WeakRef持有订阅者的内部对象，每次emit时先尝试从 WeakRef 取回，取不到说明订阅者已被 GC，顺手把这个空位从集合里删掉。要注意的是 WeakRef 的回收时机由引擎决定，不能依赖它做"确定性清理"，所以它只能作为兜底，不能替代显式退订。我的实际用法是：关键路径必须显式退订，长生命周期的事件总线才用 WeakRef 做防御。

6.2 微任务合并派发，避免重复渲染

第二节提到的batch功能，我再展开说一下实现细节。真实项目里，一次业务操作往往产生多次set，比如提交订单时要同时变更订单状态、清空购物车、增加一个提示消息。如果每次set都同步触发订阅者，页面会在一个事件循环里被渲染多次，掉帧明显。

rea 的 batch 实现是在 store 上维护一个pendingSubscribers集合，set触发时先把订阅者加进集合，而不是立刻执行；然后在同步代码全部跑完后，用queueMicrotask统一执行一次派发。执行时如果是浏览器环境，还可以和requestAnimationFrame协作，让派发时机对齐到帧渲染之前。这个优化对中后台表格这类容易高频更新的场景，体感提升非常明显。

6.3 在 React/Vue 中接入的适配思路

最后说一个很多人关心的问题：rea 怎么和前端框架结合。

在 React 里，我的做法是封装一个useReahook，内部用useSyncExternalStore订阅 rea 的路径变化。当get(path)返回的值变了，React 就重新渲染组件；不变就不渲染。因为 rea 本身能精确到字段级别触发，天然避免了大范围重渲染。Vue 那边更简单，Vue 3 的响应式系统也是 Proxy 实现的，可以直接把 rea 里的响应式对象作为 Vue 的reactive数据源混合使用，只是要注意两套 Proxy 不要嵌套混用，容易出双向劫持的问题。

接入框架的另一个经验是：不要在组件里直接订阅全局事件，而是先把事件映射成数据，再让 UI 只依赖数据。比如"切页签"这个动作，组件不应该订阅tab:change，而应该读store.get('currentTab')这个字段。事件用来做跨模块副作用，数据用来驱动视图，这条边界一旦清晰，项目里"一切皆事件"导致的不可追踪问题就自然消失了。

最后再分享一个小技巧：rea 的源码里我没有用任何装饰器语法和私有字段，所有属性都是普通可打印的对象。这意味着你在调试控制台里可以直接展开 store 的全局状态、事件表、订阅者集合，亲眼看到"这个事件有 3 个订阅者，分别是谁"。对于响应式状态库这种偏底层的工具，这种可调试性才是长期维护中最值钱的东西。如果你要自己实现一个类似的小库，也建议先保住这个优点，功能少一点没关系，出问题时能一眼看透比什么都强。