还没开工先看需求是今年一个内部项目的真实复盘。起因很简单业务方要在一个跨端小程序里跑一段“状态联动”逻辑场景是这样的——某个页面里同时挂着表单校验、列表筛选、接口轮询它们之间彼此不下发指令却要求状态自动保持一致。最早丢给我的是一个概念名叫“rea”全称是Reactive Event Adapter说白了就是一个轻量的响应式事件适配层。当时随手写了个Demo结果这玩意儿越用越顺手最后成了那个项目里最不起眼但最稳的一块砖。这篇文章就围绕“rea”这个标题来展开聊聊它到底解决什么问题、怎么设计、踩过什么坑以及怎么把这类思路套到你自己手头的项目里去。先说清楚“rea”是什么。它不是某个现成开源框架的名字而是一类“响应式事件编排器”的简称。核心职责是把各种来源的事件点击、输入、网络响应、定时器统一收敛到一个事件流里再根据你预先定义好的规则自动触发对应的一组副作用。和传统的事件总线相比rea不强调“谁发出、谁监听”而是强调“状态变化之后该发生哪些连锁反应”。适合什么人参考后端写多了想碰前端状态管理的、前端被Redux/MobX/EventBus折腾到头秃的、以及所有需要在多人协作项目里把事件逻辑收敛成“可读配置”的团队。哪怕你手头只是个用原生JS写的小页面这套思路一样能落地。1. 整体设计为什么我不用现成的状态管理库开始写代码之前我先花了一天时间梳理需求。那个页面的交互链大概是这样用户输入关键词前端先本地过滤一遍再带参请求接口接口回来要更新列表、判断空态、重置分页同时外部有个定时器每30秒刷新一次当前筛选条件下的数据。看着不复杂但现场代码是几个人接力写的有的用回调有的用全局变量还有的直接在请求里嵌套setTimeout排查起问题来非常痛苦。我最初考虑过引入现成的状态管理方案比如MobX或者Redux Toolkit。但项目本身是轻量小程序包体积敏感而且团队里不是所有人都熟悉响应式编程的思维。引入一个重框架学习成本和迁移成本都不小。于是我就想能不能自己写一个只有几百行、但刚好覆盖需求的“事件适配层”这就是“rea”的雏形。它的设计目标有三个状态源State Source统一所有会变化的数据都注册成可观察的“源”每次变化都会广播快照。副作用编排Side Effect Orchestration不写面条式回调改用声明式的“当A变化并且满足条件B则执行动作C”。可调试、可回放每一次状态变更都能留痕出问题可以直接查时间线。我选这个方案而不是EventBus是因为EventBus本质上还是“手动接线”事件多了以后根本理不清谁依赖谁。而rea的核心是“状态驱动”你只需要描述状态的依赖关系剩下的触发顺序由引擎来保证。然后这是rea的运行时抽象伪代码描述核心循环class ReaRuntime { constructor() { this.sources new Map(); this.rules []; this.snapshot {}; } registerSource(key, initialValue) { this.sources.set(key, initialValue); this.snapshot[key] initialValue; } addRule(condition, effect) { this.rules.push({ condition, effect }); } setState(key, value) { this.snapshot[key] value; this.rules.forEach(rule { if (rule.condition(this.snapshot)) { rule.effect(this.snapshot); } }); } }实际线上版本比这个复杂加了去重、异步调度、批量更新但骨架就是这个循环。每次setState都会触发一轮规则匹配命中就执行副作用非常简单。2. 核心细节解析与实操要点2.1 响应式状态源的设计“源”是整个rea的基础。我把页面里所有需要参与联动的数据全部转成可观察对象。比如当前输入框的内容、当前页码、接口返回的列表数据、加载状态。方法很简单用一个set函数包一层写入逻辑内部做前后值比较变了才广播。这里第一个坑就是对象引用比较。我们列表数据每次接口返回都是个新数组如果用“!”判断那每次都“变了”就会无限刷新。我的处理方法是对于数组比较length和首元素地址浅标记对于对象比较JSON序列化后的hash。够用就好别过度设计。页面里就那几十种状态序列化一次的花费可以忽略。第二个坑是注册顺序无关性。实际业务里规则可能会引用还没注册的状态。比如“A变化时更新B”但B还没初始化。我在registerSource里就把默认值写进snapshot了所以addRule的时候哪怕状态不存在条件函数里访问到的也是undefined或者你指定的初值不会直接报错。这个设计对团队协作特别有帮助新成员不用关心“这个状态有没有被先定义”。2.2 副作用编排的规则引擎规则引擎是核心中的核心。我总结了一套自己的写法每条规则拆成三个部分触发状态watch、生效条件when、执行动作then。用中文描述就是“当watch里的这些状态发生变化并且when返回true就执行then”。实际代码看起来像这样rea.addRule({ id: filter-trigger, watch: [keyword], when: (ctx) ctx.keyword.length 2, then: (ctx) { ctx.page 1; loadList(ctx.keyword); } });注意watch和when的区别。watch是用来做“变化监听”的只有被watch的字段发生改变引擎才会去检查这条规则而when是在watch条件满足之后做的二次判断。这样做的性能好处是如果某个与规则无关的状态疯狂变化规则根本不会被评估。还有一种场景需要特别注意多个规则互相触发。比如规则A里更新了规则B的watched状态规则B的then里又更新了规则A的watched状态就会形成死循环。我通过一个简单的调用深度计数器来解决同一个事件循环内如果某条规则被连续触发超过20次就判定为循环并直接报错同时把最近10次的变更记录打印出来。2.3 批量更新与调度策略在原生开发里频繁setState很容易引发渲染抖动。我刚开始做的时候keyword每次输入都直接触发loadList结果用户还没打完字接口已经发了十几二十个请求。后来我在rea里加入了“批量调度”// 手动开启一个事务 rea.batch(() { rea.setState(keyword, input); rea.setState(page, 1); rea.setState(tab, all); });batch内部先把所有setState存进队列等batch回调执行完后统一进行一次规则评估。这样规则只会在所有状态都更新完后跑一遍而不是每set一个就跑一次。实现也很简单用一个isBatch标志位加一个待执行队列。这个优化对体验的提升非常明显。原先输入一个中文词组要触发5、6次联动现在全部合并成一次。而且batch里如果同时改了多个watch源规则也只跑一次then天然去重。3. 实操过程与核心环节实现3.1 环境准备与基础封装项目用的是原生小程序语法没有引入额外的npm包。我建了一个rea.js工具文件大概300行封装了前面说的源管理、规则引擎、批量更新和日志。没有采用类Class而是用了闭包单例因为整个页面只需要一个运行时多个页面之间互不共享。文件结构是这样├── core/ │ ├── rea.js # 运行时核心 │ ├── sources.js # 状态源定义 │ └── rules.js # 规则配置 └── page/ ├── index.js # 页面逻辑 └── index.wxml # 模板我更推荐把sources和rules单独拆成文件而不是塞进页面逻辑里。理由很简单业务状态一多规则会越来越长如果和页面渲染混在一起用不了多久就没人愿意看代码。拆开以后sources.js里是一堆初始值rules.js里是一堆声明式描述读起来很快。3.2 从零开始搭建第一个rea规则拿我们项目中最经典的一个场景说用户切换Tab时重置列表页码并重新加载数据。传统写法是page.onChangeTab里写三行代码用rea之后是这样// sources.js rea.registerSource(activeTab, 0); rea.registerSource(page, 1); rea.registerSource(listData, []); // rules.js rea.addRule({ id: tab-change-refresh, watch: [activeTab], then: () { rea.setState(page, 1); Promise.resolve().then(loadList); } });这里我特意用了Promise.resolve().then来延迟执行loadList原因是当前规则评估还在rea的事务栈里直接调用loadList可能会在函数内部又setState造成嵌套触发。用微任务切入可以把“当前更新”和“后续副作用”剥离开来。这个场景看似简单但有个细节踩坑很深当Tab从“全部”切到“已完成”时如果“已完成”下面没有数据空态组件要展示。同时列表头部有一个“总共N条”的文案也要跟着变。如果这些都用watch字段去监听就得监听listData的变化然后重新计算总数。但listData是一个大数组频繁改动性能不好。我的做法是在then里只更新page和loading列表数据的更新由另一个专门负责“数据清洗”的规则来处理两个规则之间通过同一个snapshot传递中间结果尽量别直接改对方的输入。3.3 异步数据流的接入方式页面里必然有接口请求。rea的规则引擎是同步的但接口请求是异步的。这里我采用了最笨但最可靠的方案接口请求放在规则的then里发起然后接口回调里再调用rea.setState去更新“接口状态”这个源。这样整个数据流就是闭环了。举个例子// rules.js rea.addRule({ id: load-when-filter, watch: [keyword, page], when: (ctx) ctx.keyword.length 0, then: async (ctx) { rea.setState(loading, true); try { const data await api.fetchList({ kw: ctx.keyword, page: ctx.page }); rea.setState(listData, data.list); } finally { rea.setState(loading, false); } } });需要注意这里then是async函数rea引擎不会等待它完成也不会阻止其他规则同时触发。如果你有多个规则同时发请求你需要在每个请求里带上一个“请求序号”然后回调时校验该序号是否仍是最新的否则会拿到旧接口的过期数据。这个“请求竞态”问题困扰了我一个多星期最终我是用一个小工具函数解决的在页面里维护一个requestSeq每次发请求前自增回调里只处理序号等于最新值的返回。3.4 日志与调试机制的隐藏价值rea最实用的功能之一就是内置的日志系统。每次setState、每次规则触发都会推一条结构化日志进一个环形buffer。线上遇到用户反馈异常时我只需要在小程序后台把这些日志拉出来就能还原出用户在页面上的完整操作路径。举个例子用户说“我明明搜索了列表却是空的”。日志一下就看出来搜索关键词太短被when拦截掉了根本就没触发接口请求或者触发了但接口返回异常被finally兜底了。之前排查事件链要靠人肉在控制台打log现在全自动。我强烈建议在生产环境保留环形日志只存最近的200条事件每条记录包含时间戳、源名称、before/after值、触发的规则ID。内存开销非常低但排查问题的效率提升是成倍的。4. 常见问题与排查技巧实录4.1 我踩过的那些“同步地狱”最典型的问题就是规则A改了状态X页面还没来得及渲染规则B就读取了X的新值。比如切换Tab时A规则把page重置成1B规则立刻根据page去请求数据但此时页面上的分页组件还停留在旧页码。过了100毫秒分页组件才同步过来。解决办法是对于外部组件小程序View、自定义组件里的状态不要去监听“组件如何被动更新”而是让更新动作直接调用组件自己的set方法。在rea规则里希望联动到组件的地方都尽量只调用“肉眼可见的副作用”而不是偷偷改全局态再指望组件自动感知。因为小程序的数据监听机制和Vue的响应式不一样它更接近“手动绑定”。rea改完全局态后组件其实不会立刻知道自己“变了”还需要显式地setData。这个坑特别隐蔽排查了很久才明白。4.2 循环触发的定位方法前面提到我用连续触发计数来拦截循环。这里给一个更具体的案例。我们有两个状态keyword搜索词和suggestion联想词。规则A监听keyword更新suggestion规则B监听suggestion反过来把keyword补全。当用户输入“abc”A把suggestion变成“abcd”B又触发补全keyword变成“abcd”A又跑一遍……如果没有拦截机制页面会直接卡死。我当时用计数器抓到循环后日志里把规则ID和触发顺序打印出来一眼就定位到矛盾点。解决方式很简单给规则B的when加一个判断只有当前端检测到用户在输入时才执行补全而不是任何情况下都补。排查循环的逻辑核心是识别“两个规则之间构成了并行环”。只要把其中一个环路的边断开或者加一个状态锁问题就解决了。4.3 性能优化现在跑起来一点不卡优化方面踩了两个点。第一是watch列表太长。我最初把所有状态都挂在“全局感知”里每条状态变化都会遍历所有规则。结果数量一多键盘输入时每个字符都会触发遍历几百条规则肉眼可见的卡。后来把watch分成“高频小集合”和“低频大集合”高频的输入、滑动、loading单独建一个轻量引擎。第二是snapshot的深拷贝。某些依赖数据的规则需要读取整个listData如果每次setState都深拷贝整个数组内存开销会非常大。我是通过“按需getter”解决的规则里不要调用ctx.listData直接拿数据而是用ctx.get(listData)。这个方法内部做了惰性拷贝只有真正读取时才复制当前值。4.4 常见问题速查表现象可能原因解决方案规则触发次数明显比预期多对象引用每次set都变化对数组/对象做浅层hash接口请求发了很多次实际需要1次缺少batch合并手动开启rea.batch包裹用户快进快到页面数据串了请求竞态给每个请求带序号回调校验最新值页面卡住控制台大量repeat日志规则互相触发循环加循环计数拦截定位互相依赖规则某些组件状态没更新只改了全局态没同步组件在规则then里显式调用组件setData改动一个基础状态整个界面都重刷watch列表过长拆分高频和低频的两套watch集合Async规则异常吞掉后续联动缺少try/finallyfinally里强制恢复loading状态调试时期望看历史变更没数据没有开启日志/日志被清空预留环形buffer保留200条日志排查技巧的底层逻辑就一句话把“谁动了什么”变成可查的记录。只要事件链路的每一步都有日志问题基本都能在半小时内定位。5. 工具选型与扩展方向5.1 什么时候选rea什么时候该用成熟方案说了这么多优点也得说说边界。rea适合的是中小型项目中“状态联动规则清晰”的场景。如果你要做的是超大型单页应用状态依赖关系几百条起步我建议直接上成熟的响应式状态库人家背后有完整的优化方案和社区踩坑记录。但如果你手头就是个小程序、一个运营后台、或者一个配置驱动的H5页面基础的前端框架已经把渲染和DOM管理做掉了只缺一个“事件联动层”那rea这种自研轻量引擎绝对是性价比最高的一步。它不侵入你现有的代码结构也不会让全组人重学一套概念。5.2 怎么把rea扩展成全局状态库如果你想在更大范围里复用rea可以做几层扩展持久化把snapshot序列化到localStorage页面刷新后还原现场。跨页面通信把rea的setState包装成一个IPC消息两个页面实例共享同一个状态树。开发工具集成在Chrome插件里实时展示状态变化时间线点击某条规则可以直接重放变更。这三个扩展方向里持久化最实用。我在另一个项目里就在setState的底层做了一个debounce保存每500ms把snapshot写入存储。用户杀进程重新进入后完全恢复到退出前的界面状态体验很好。5.3 一段成熟的rea配置长什么样我把某个页面最终稳定下来的rea配置精简一下你大概感受下它的可读性rea .source(keyword, ) .source(page, 1) .source(listData, []) .source(loading, false) .rule({ id: input-debounce-search, watch: [keyword], when: (ctx) ctx.keyword.trim().length 2, then: (ctx) { rea.batch(() { rea.setState(page, 1); rea.setState(loading, true); }); fetchList(ctx.keyword, 1); } }) .rule({ id: scroll-load-more, watch: [page], when: (ctx) ctx.page 1, then: (ctx) { rea.setState(loading, true); fetchList(ctx.keyword, ctx.page); } });链式调用很舒服新同事看这几十行基本就能上手维护页面了不需要知道背后的实现细节。我认为这才是状态管理该有的样子让业务逻辑看起来就是一份“决策说明书”而不是一团埋没在代码里的隐式回调。结尾的实际体会最后再分享一个从这次实践中悟到的东西。最初我以为自己是在写一个“状态管理工具”做到后期才发现真正难的是给你的项目建立“事件边界意识”——哪些变化是核心状态、哪些是派生状态、哪些是纯粹副作用。rea只是把这个边界用代码表达出来了。如果手头也有这种“多条件联动”的项目建议别急着套用重型框架先用一个轻量脚本把状态和规则分开描述试试。你可能会发现代码突然变得异常老实调试也不再靠猜。至少我现在已经离不开这套思路了。