声明本文内容完全基于虚构场景创作不涉及任何真实产品、公司及个人信息仅为技术经验分享。写这篇东西的起因挺简单我在某次接手的遗留项目里被一个全局状态对象搞得头皮发麻。四十多个字段散落在不同模块里改一个值要翻遍调用链竞态问题像韭菜一样割了一茬又一茬。当时市面上不是没有现成的方案但要么重得要命要么和项目现有的渲染机制纠缠不清。折腾了几晚之后我索性自己写了一个轻量级的状态响应方案代号就叫“rea”全称我开玩笑地解释为“Reactive Everything App”。现在这个小框架已经在我手上几个项目里跑了快一年稳定得让人安心所以我把拆解思路、核心实现和踩坑实录整理出来希望能给同样被状态管理折磨的朋友一些参考。先说清楚这东西是什么、能干什么rea本质上是一个极简的响应式数据流核心以“模型-派发-订阅”三层结构组织业务状态核心代码只有三百多行依赖为零不需要学习复杂概念就能上手。它最适合的场景是中后台系统、复杂表单联动、实时看板这类需要大量跨模块同步状态的项目也适合想要理解响应式底层原理的人当作源码阅读样本。无论你用的是原生JS、React还是Vue都能用几十行代码把它接进现有工程里。下面我从设计思路、核心模块、实操步骤和问题排查四个维度完整拆一遍。1. 项目核心思路与方案设计动手写rea之前我先把自己对状态管理的核心诉求列了个清单。当时手头那个项目有几个特别折磨人的特征第一业务状态分散但没有特别复杂的实体关系用重型数据层有点杀鸡用牛刀第二页面更新依赖的是组件库自带的响应式机制但状态变更的源头在各个独立的业务模块里互相之间没有解耦第三项目里已经有不少老旧代码不能因为引入状态层就把现有生命周期推倒重来。所以我的目标很明确做一个足够薄、足够透明、接入成本极低的中间层只负责两件事状态变更的统一收口以及变更之后的通知扩散。1.1 为什么不用现成的重型方案市面上成熟的状态管理库不是不好而是对当前项目来说太“重”。大多数方案都要求你把业务逻辑挂到统一的store树里再通过长长的selector函数链去取数据这在大型复杂项目里是优势但在中小型模块里反而成了负担。引用链一长调试时就要在各层之间跳来跳去心智负担并不小。更重要的是这些方案往往绑定了一套自己的更新调度机制和项目里已经存在的渲染管线叠加后容易出现重复渲染或者更新顺序不可控的问题。我需要的不是另一个“官方推荐最佳实践”而是一个不管放在哪段代码里都能用的稳定基座。所以rea的设计原则定为三条第一不重复造渲染器的轮子只做状态变更和通知的纯逻辑层第二状态模型独立于任何框架存在视图层通过几行适配代码接入第三所有异步流程都收口到中间件链路上方便统一处理错误和日志。1.2 rea的总体架构rea整体只有三层模型层、派发层、订阅层。模型层负责定义数据结构与初始值派发层接收动作并调用对应的变更函数订阅层负责把变更广播给所有注册过的回调函数。这个结构和很多成熟方案的骨架类似但我刻意把每一层都做得特别薄避免引入框架层面的重概念。打个比方传统方案像一个中央政务大厅所有业务都要到大厅排队办理好处是有序坏处是高峰期拥堵rea更像一个社区公告栏谁家有变化就把新的通知贴上去关心的人自己来看。这种模式在小范围数据同步场景里非常自然不会有排队压力也不存在跨窗口调度延迟。1.3 对“响应式”的理解“响应式”听起来高大上本质其实特别简单数据变用它的地方跟着变。问题在于不同框架对“用它的地方”定义不一样React认为“用到”就是组件函数执行完之前读取过Vue认的是依赖收集原生JS开发时则得自己维护订阅列表。rea不打算统一这些哲学只暴露一个最朴素的接口onChange(callback)由各渲染环境自己决定如何把callback变成视图更新。这样设计的好处是框架无关坏处是没法享受框架级依赖追踪带来的精细更新但对中后台场景完全够用——毕竟这类页面的状态量级基本在几百个字段以内全量通知的代价微乎其微。2. 核心模块与关键技术解析搞清楚了要什么接下来就是动手实现。这一节我会把每个核心模块的设计思路、代码骨架和关键取舍讲透。代码都用TypeScript来描述因为类型提示对日常使用太重要了后面你会看到几个靠类型就能避免的坑。2.1 模型层数据结构与初始状态模型层是整个rea的起点。它要做的事情只有一件描述业务数据长什么样初始值是什么。我借鉴了数据库建表的思想每个模型对应一个业务域比如用户信息、购物车、筛选条件每个域有自己明确的字段定义。// model.ts export interface ModelSchema { name: string; state: Recordstring, any; } export function defineModelT extends Recordstring, any(name: string, state: T) { return { name, initState: { ...state }, }; }注意我刻意把初始状态做了浅拷贝而不是直接存引用。这一点吃过亏如果直接保存原对象后续调用方可能无意间修改了初始状态导致重置功能失灵。浅拷贝只花纳秒级的时间却能挡住一类特别隐蔽的bug。模型定义之后store会为每个模型维护一份“当前状态”和一份“初始状态”前者用于业务读取后者用于重置场景。为什么需要两份因为很多业务都有“恢复默认筛选”“清空表单”这样的需求如果没有初始状态快照就得手工写一堆重置逻辑。2.2 派发层动作与变更函数收口状态不能直接改必须通过派发动作触发变更。这部分设计参考了命令模式调用方不必关心状态具体怎么变只需要描述“我想做什么”具体的变更逻辑由注册在模型上的reducer函数完成。之所以收口是为了让所有状态变化都经过同一条链路方便打日志、做埋点、加中间件和统一错误处理。// dispatch.ts export type ReducerT (state: T, payload?: any) PartialT | void; export class Store { private models: Mapstring, ModelInstance new Map(); register(model: ModelSchema, reducers: Recordstring, Reducerany) { // 注册模型和对应的变更函数集合 // 每个reducer函数会在收到动作后被调用返回值浅合并到当前状态 } dispatch(modelName: string, actionName: string, payload?: any) { const instance this.models.get(modelName); const reducer instance.reducers[actionName]; const patch reducer(instance.state, payload); if (patch) { instance.state { ...instance.state, ...patch }; } this.notify(modelName, actionName, payload); } }这部分的精妙之处在于返回值只做浅合并。也就是说reducer里不用把整个状态对象都return出来只返回有变化的字段即可。很多人第一次用会不习惯老想着返回整个新状态。其实浅合并的价值在于减少样板代码也能避免误操作覆盖掉其他字段。深层嵌套的数据变更怎么办我的建议是reducer内部创建更新后的嵌套对象再返回比如return { user: { ...state.user, name: payload.name } }。这个模式虽然多写几行但胜在简单可靠。2.3 订阅层变更通知的广播机制订阅层是rea和视图层之间的桥梁。它维护一个回调函数数组dispatch完成状态合并后立刻逐个调用回调然后把动作名称和载荷数据传出去。和很多“发布-订阅”实现不同的是我额外支持了“订阅指定的某几个字段”只有这些字段的值变了才会触发回调。// subscribe.ts type Listener (patch: any, actionName: string) void; class ModelInstance { private listeners: SetListener new Set(); subscribe(listener: Listener) { this.listeners.add(listener); return () this.listeners.delete(listener); } }字段级订阅是我在项目演化过程中加上的。最开始只做全量通知后来发现筛选页有十几个互不相关的模块都订阅了同一个store一个模块更新会导致所有模块重新拉数据。性能优化一轮之后我给subscribe增加了一个可选参数字段筛选器。订阅者传入一个数组比如[filters]只有当本次变更的patch里包含filters字段时才触发回调。这个设计在实际项目中节省了大量不必要的组件更新且实现成本不过是一个Array.some。2.4 中间件拦截一切状态流转中间件是我整套架构里最得意的一块。调用方可以注册若干函数在reducer执行之前或之后介入。之前主要用于打日志后来发现还可以做权限校验、异步请求埋点、错误上报。中间件的实现并不复杂本质上就是一个函数数组在dispatch流程中按顺序执行type Middleware (context: DispatchContext, next: () void) void; function runMiddlewares(middlewares: Middleware[], context: DispatchContext) { let index 0; const next () { const mw middlewares[index]; if (!mw) return; mw(context, next); }; next(); }这种洋葱圈模型可能有人眼熟但rea的中间件上下文里只包含模型名、动作名、载荷、当前状态和补丁对象没有多余概念。这样中间件可以做得非常纯粹测试也容易。项目里最常用的中间件是一个异步日志器它会记录每个动作前后状态的变化差异并输出到控制台。调复杂bug的时候把日志拉出来对比前后状态基本一眼就能定位问题。3. 实操过程从零搭一个rea应用理论讲再多不如直接上手写一个完整项目。我挑了一个典型场景购物车面板。它包含商品列表、已选数量、总价、优惠码和结算状态状态之间有不少联动关系非常适合演示rea的能力。最终效果是一个原生TS写的页面不依赖任何框架直接用DOM API渲染。3.1 工程初始化与核心接入先用npm初始化一个空的TypeScript工程安装必要的开发依赖。这里选择Vite作为开发服务器因为它的构建速度和热更新体验都很好而且配置几乎为零。npm create vitelatest rea-demo -- --template vanilla-ts cd rea-demo npm install装完之后做两件事第一件是打开tsconfig.json确认strict模式为true第二件是把rea的四个核心文件复制进src/core目录。我自己的项目中rea核心代码包含model.ts、store.ts、subscribe.ts和middleware.ts一共300多行。细节提醒strict模式必须开。后面你会看到如果类型是any泛滥字段级订阅的场景里很可能出现拼写错误导致订阅失效而strict能在编译期帮你兜住一部分低级错误。3.2 定义购物车模型购物车业务域的第一步是定义数据结构和初始值。我列了这么几个字段商品列表、选中的商品ID集合、优惠码、结算状态。初始值都是空或者默认值保证任何时候重置模型都能回到“车是空的”这个原点。// src/models/cart.ts import { defineModel } from ../core/model; export const cartModel defineModel(cart, { items: [ { id: p1, name: 机械键盘, price: 399, count: 1 }, { id: p2, name: 显示器支架, price: 159, count: 2 }, ], selectedIds: [] as string[], promoCode: , status: idle, // idle | checking | success | error });商品列表里的价格和数量是模拟写死的实际项目里这些数据会来自接口。把状态设计成“初始化时为空、使用时填充”还是“初始化时放着默认数据”我的经验是凡是涉及展示型页面初始值尽量接近真实场景这样开发调试时不用每次手动造数据凡是涉及提交型流程初始值一律空避免误用脏数据。3.3 注册reducer与动作状态结构定了接下来注册变更逻辑。我按业务动作拆了一批reducer添加商品、勾选/取消勾选、应用优惠码、设置结算状态。每个reducer只负责一个明确的小动作命名也尽量动词化。import { cartReducer } from ./cartReducer; export const cartActions { addItem: (payload: { id: string; name: string; price: number }) ({ items: pushItem(cartReducer.state, payload), // 简化描述 }), toggleSelect: (payload: { id: string }) { const selected new Set(cartReducer.state.selectedIds); selected.has(payload.id) ? selected.delete(payload.id) : selected.add(payload.id); return { selectedIds: [...selected] }; }, // ... 其他动作 };注意reducer函数不应该直接修改state而是返回补丁对象。这是rea的铁律。补丁对象会被浅合并到当前状态里整个过程不会破坏原对象的引用。这一点对性能优化很重要如果组件通过浅比较来决定是否重新渲染那么不变的部分引用完全一致可以跳过diff。3.4 用订阅驱动DOM更新原生TS项目没有虚拟DOM所以我用一个简单函数把store状态渲染到页面上。页面里有三个主要区域商品列表、选中摘要和结算结果。当任意状态发生变化时重新渲染全部并不划算所以我利用字段级订阅来精确控制更新范围。// src/main.ts import { createStore } from ./core/store; import { cartModel } from ./models/cart; import { cartActions } from ./models/cartActions; const store createStore(); store.register(cartModel, cartActions); // 渲染选中摘要 const renderSummary () { const state store.getState(cart); const total state.selectedIds.reduce((sum, id) { const item state.items.find(it it.id id); return sum (item ? item.price * item.count : 0); }, 0); document.getElementById(summary)!.textContent 已选 ${state.selectedIds.length} 件合计 ¥${total}; }; // 订阅selectedIds字段变化时仅更新摘要区 store.subscribe(cart, renderSummary, [selectedIds]);这段代码里订阅的第三个参数是关键它告诉rea我只需要在选中集合变化时重新计算总价。如果商品单价改了、优惠码变了摘要区的render不会多余执行自然也不会引起无谓的DOM操作。这就是字段级订阅带来的可感知性能提升。3.5 处理异步流程优惠码校验购物车里最容易踩坑的是异步操作。以优惠码校验为例用户输入一串码点击应用后需要请求服务端确认优惠码是否有效期间按钮要置灰完成后要更新最终价格。用rea实现这个流程时我先触发一个status: checking的动作然后发起请求拿到结果后再触发成功或失败的动作。async function applyPromoCode(code: string) { store.dispatch(cart, setStatus, { status: checking }); try { const result await mockRequest(code); if (result.valid) { store.dispatch(cart, applyPromo, { promoCode: code, discount: result.discount }); } else { store.dispatch(cart, setError, { error: 优惠码无效 }); } } finally { store.dispatch(cart, setStatus, { status: result.valid ? success : error }); } }这里要特别强调一点异步操作完成后必须继续走dispatch更新状态不要尝试直接修改仓库里的数据对象。原因很简单如果你绕过了dispatch中间件和订阅链路全部失效页面不会刷新还会留下难以追踪的隐性状态。我在代码里加了一个开发环境的守卫函数直接在store实例上挂一个assertNotFrozen的逻辑每当state被补丁合并后就递归冻结对象任何绕过dispatch修改属性的行为都会在严格模式下抛错。这个操作对性能有点影响但只在开发模式启用收益远大于开销。4. 常见问题与排查实录rea用了快一年实际项目中遇到的坑不少但基本上都能用同一套思路解决。我整理了五个最典型的问题都是真实发生过的场景每个都给出排查步骤和最终方案。4.1 修改了对象但视图不更新这个问题的现象是dispatch执行了日志也打印了页面就是不动。排查后发现绝大多数原因都是reducer直接修改了原state的嵌套对象。比如有人写return { user: { ...state.user, name: new name } };这是正确的。但如果写成state.user.name new name; return {};就有麻烦了。因为浅合并只会对比第一层字段user的引用没有改变订阅器自然认为没有变化。解决方式有两个一是严格执行“不修改原状态返回新对象”的规范二是在订阅触发时不做浅比较而是做深度比较但深度比较性能代价高所以我只在开发模式开启。4.2 异步竞态导致最终状态错乱这是最隐蔽的坑之一。场景是这样的用户在搜索框里快速输入每输入一个字就触发一次异步请求。结果A请求比B请求晚发出但先返回了页面显示的内容就来自旧请求。后来我加了请求序号作为守卫每次请求发出前递增计数器回包后比较序号只有最大序号的请求才允许进入状态更新。这个方案反应快且实现成本低。let requestSeq 0; async function search(keyword: string) { const seq requestSeq; const result await mockRequest(keyword); if (seq ! requestSeq) return; // 过期响应直接丢弃 store.dispatch(search, setResult, result); }这个方法简单得让人不敢置信但它确实解决了我项目里90%以上的竞态问题。更复杂的场景可以引入AbortController但对大多数业务来说序号守卫已经足够。4.3 内存泄漏订阅回调越积越多有段时间页面上某些组件会越跑越慢浏览器最终甚至会卡死。用性能分析工具一看监听器数量爆炸了。原因特别低级组件每次挂载都会调用subscribe但在卸载时忘记了调用返回值里的取消函数。后来我学乖了把subscribe的返回值设计成销毁器在组件卸载时统一调用。如果你的工程是React还可以封装一个useReaSubscription的钩子内部用useEffect返回清理函数从根源上杜绝泄漏。4.4 性能瓶颈大列表里每个项目都订阅电商后台有那种一次性渲染几百个商品卡片的大列表每个卡片里的选择状态都要和全局store同步。如果每个卡片都单独订阅全局字段会造成大量无效回调。我优化成“只订阅可见区域”的模式列表区只订阅一个visibleRange字段滚动时通过变换range来触发渲染卡片本身不直接订阅store。这个改动让长列表的内存占用量直接降了四成滚动流畅度也有了质的提升。把“每一个小部件都有全局状态”变成“区域持有状态、部件只渲染”这个思路不仅适用于rea也适用于任何前端状态方案。4.5 中间件顺序混乱导致日志不完整加中间件时有一次把日志中间件放在了错误处理中间件之后结果错误发生的时候日志反而记录不到。这促使我制定了中间件注册规范打日志类中间件永远排在最外层错误处理靠内层最后才是核心业务中间件。因为洋葱模型的执行顺序决定了外层中间件最先拿到context、最后拿到结束信号所以日志放在外层能看到最完整的链路。这个规范后来被我写进了团队的前端代码规范文档里。中间件这一层能做的远比打日志多还有团队拿它做无侵入埋点服务端状态都在这一层给收口了后续接分析平台只需要加一段适配代码业务代码一行都不用动。5. 项目扩展与生态思考rea目前已经是一个可以实际使用的内核但我经常被问到它能不能做更多事情。其实把核心逻辑往上叠并不难真正难的是保持这套架构的纯粹性。每次想加东西我都先问自己三个问题这是不是所有业务域都需要的通用能力如果放在业务层能解决是不是其实不该进核心这个能力会不会逼迫使用方改变原有的写法基于这个原则我梳理了两个目前觉得值得做、但还没做进核心的功能持久化和跨标签页同步。持久化很直观把store状态的变化订阅下来节流后写入localStorage应用启动时读取并注册为初始值。跨标签页同步本质上是同一套操作日志在不同页面的广播用BroadcastChannel接上就能跑。这两个功能都能以中间件的形式实现代码量不大但放进主仓库反而会让初学者困惑所以我选择把它们作为扩展包维护。另外如果有人想把rea接进React我自己常用的适配方式是写一个useStore钩子内部用useSyncExternalStore把store变化映射为组件重新渲染。这样写的好处是完全不用改动核心代码适配层只有四五行。import { useSyncExternalStore } from react; export function useStore(store, modelName, fieldSelector) { return useSyncExternalStore( (callback) store.subscribe(modelName, callback, fieldSelector), () store.getState(modelName) ); }这也再次印证了前面说的核心越薄生态越容易扩展。最后再分享一个我在实际运维中最受益的小习惯给每个store模型写一个单元测试文件把关键的reducer流转用表驱动的方式测一遍。rea的reducer是纯函数测试起来非常舒服不需要mock任何东西。每次重构核心代码后跑一圈测试底色立刻就看得到。说真的这么薄的一个状态层最大的敌人不是功能缺失而是开发者在“图方便”的念头下不断往核心塞东西。守住“小而稳”的边界这套方案的长期价值才会真正体现出来。 
长河君 · 2026/10/16 16:19:10 · 阅读 1.2k 轻量级响应式状态管理核心设计与实现：三百行代码构建数据流
声明本文内容完全基于虚构场景创作不涉及任何真实产品、公司及个人信息仅为技术经验分享。写这篇东西的起因挺简单我在某次接手的遗留项目里被一个全局状态对象搞得头皮发麻。四十多个字段散落在不同模块里改一个值要翻遍调用链竞态问题像韭菜一样割了一茬又一茬。当时市面上不是没有现成的方案但要么重得要命要么和项目现有的渲染机制纠缠不清。折腾了几晚之后我索性自己写了一个轻量级的状态响应方案代号就叫“rea”全称我开玩笑地解释为“Reactive Everything App”。现在这个小框架已经在我手上几个项目里跑了快一年稳定得让人安心所以我把拆解思路、核心实现和踩坑实录整理出来希望能给同样被状态管理折磨的朋友一些参考。先说清楚这东西是什么、能干什么rea本质上是一个极简的响应式数据流核心以“模型-派发-订阅”三层结构组织业务状态核心代码只有三百多行依赖为零不需要学习复杂概念就能上手。它最适合的场景是中后台系统、复杂表单联动、实时看板这类需要大量跨模块同步状态的项目也适合想要理解响应式底层原理的人当作源码阅读样本。无论你用的是原生JS、React还是Vue都能用几十行代码把它接进现有工程里。下面我从设计思路、核心模块、实操步骤和问题排查四个维度完整拆一遍。1. 项目核心思路与方案设计动手写rea之前我先把自己对状态管理的核心诉求列了个清单。当时手头那个项目有几个特别折磨人的特征第一业务状态分散但没有特别复杂的实体关系用重型数据层有点杀鸡用牛刀第二页面更新依赖的是组件库自带的响应式机制但状态变更的源头在各个独立的业务模块里互相之间没有解耦第三项目里已经有不少老旧代码不能因为引入状态层就把现有生命周期推倒重来。所以我的目标很明确做一个足够薄、足够透明、接入成本极低的中间层只负责两件事状态变更的统一收口以及变更之后的通知扩散。1.1 为什么不用现成的重型方案市面上成熟的状态管理库不是不好而是对当前项目来说太“重”。大多数方案都要求你把业务逻辑挂到统一的store树里再通过长长的selector函数链去取数据这在大型复杂项目里是优势但在中小型模块里反而成了负担。引用链一长调试时就要在各层之间跳来跳去心智负担并不小。更重要的是这些方案往往绑定了一套自己的更新调度机制和项目里已经存在的渲染管线叠加后容易出现重复渲染或者更新顺序不可控的问题。我需要的不是另一个“官方推荐最佳实践”而是一个不管放在哪段代码里都能用的稳定基座。所以rea的设计原则定为三条第一不重复造渲染器的轮子只做状态变更和通知的纯逻辑层第二状态模型独立于任何框架存在视图层通过几行适配代码接入第三所有异步流程都收口到中间件链路上方便统一处理错误和日志。1.2 rea的总体架构rea整体只有三层模型层、派发层、订阅层。模型层负责定义数据结构与初始值派发层接收动作并调用对应的变更函数订阅层负责把变更广播给所有注册过的回调函数。这个结构和很多成熟方案的骨架类似但我刻意把每一层都做得特别薄避免引入框架层面的重概念。打个比方传统方案像一个中央政务大厅所有业务都要到大厅排队办理好处是有序坏处是高峰期拥堵rea更像一个社区公告栏谁家有变化就把新的通知贴上去关心的人自己来看。这种模式在小范围数据同步场景里非常自然不会有排队压力也不存在跨窗口调度延迟。1.3 对“响应式”的理解“响应式”听起来高大上本质其实特别简单数据变用它的地方跟着变。问题在于不同框架对“用它的地方”定义不一样React认为“用到”就是组件函数执行完之前读取过Vue认的是依赖收集原生JS开发时则得自己维护订阅列表。rea不打算统一这些哲学只暴露一个最朴素的接口onChange(callback)由各渲染环境自己决定如何把callback变成视图更新。这样设计的好处是框架无关坏处是没法享受框架级依赖追踪带来的精细更新但对中后台场景完全够用——毕竟这类页面的状态量级基本在几百个字段以内全量通知的代价微乎其微。2. 核心模块与关键技术解析搞清楚了要什么接下来就是动手实现。这一节我会把每个核心模块的设计思路、代码骨架和关键取舍讲透。代码都用TypeScript来描述因为类型提示对日常使用太重要了后面你会看到几个靠类型就能避免的坑。2.1 模型层数据结构与初始状态模型层是整个rea的起点。它要做的事情只有一件描述业务数据长什么样初始值是什么。我借鉴了数据库建表的思想每个模型对应一个业务域比如用户信息、购物车、筛选条件每个域有自己明确的字段定义。// model.ts export interface ModelSchema { name: string; state: Recordstring, any; } export function defineModelT extends Recordstring, any(name: string, state: T) { return { name, initState: { ...state }, }; }注意我刻意把初始状态做了浅拷贝而不是直接存引用。这一点吃过亏如果直接保存原对象后续调用方可能无意间修改了初始状态导致重置功能失灵。浅拷贝只花纳秒级的时间却能挡住一类特别隐蔽的bug。模型定义之后store会为每个模型维护一份“当前状态”和一份“初始状态”前者用于业务读取后者用于重置场景。为什么需要两份因为很多业务都有“恢复默认筛选”“清空表单”这样的需求如果没有初始状态快照就得手工写一堆重置逻辑。2.2 派发层动作与变更函数收口状态不能直接改必须通过派发动作触发变更。这部分设计参考了命令模式调用方不必关心状态具体怎么变只需要描述“我想做什么”具体的变更逻辑由注册在模型上的reducer函数完成。之所以收口是为了让所有状态变化都经过同一条链路方便打日志、做埋点、加中间件和统一错误处理。// dispatch.ts export type ReducerT (state: T, payload?: any) PartialT | void; export class Store { private models: Mapstring, ModelInstance new Map(); register(model: ModelSchema, reducers: Recordstring, Reducerany) { // 注册模型和对应的变更函数集合 // 每个reducer函数会在收到动作后被调用返回值浅合并到当前状态 } dispatch(modelName: string, actionName: string, payload?: any) { const instance this.models.get(modelName); const reducer instance.reducers[actionName]; const patch reducer(instance.state, payload); if (patch) { instance.state { ...instance.state, ...patch }; } this.notify(modelName, actionName, payload); } }这部分的精妙之处在于返回值只做浅合并。也就是说reducer里不用把整个状态对象都return出来只返回有变化的字段即可。很多人第一次用会不习惯老想着返回整个新状态。其实浅合并的价值在于减少样板代码也能避免误操作覆盖掉其他字段。深层嵌套的数据变更怎么办我的建议是reducer内部创建更新后的嵌套对象再返回比如return { user: { ...state.user, name: payload.name } }。这个模式虽然多写几行但胜在简单可靠。2.3 订阅层变更通知的广播机制订阅层是rea和视图层之间的桥梁。它维护一个回调函数数组dispatch完成状态合并后立刻逐个调用回调然后把动作名称和载荷数据传出去。和很多“发布-订阅”实现不同的是我额外支持了“订阅指定的某几个字段”只有这些字段的值变了才会触发回调。// subscribe.ts type Listener (patch: any, actionName: string) void; class ModelInstance { private listeners: SetListener new Set(); subscribe(listener: Listener) { this.listeners.add(listener); return () this.listeners.delete(listener); } }字段级订阅是我在项目演化过程中加上的。最开始只做全量通知后来发现筛选页有十几个互不相关的模块都订阅了同一个store一个模块更新会导致所有模块重新拉数据。性能优化一轮之后我给subscribe增加了一个可选参数字段筛选器。订阅者传入一个数组比如[filters]只有当本次变更的patch里包含filters字段时才触发回调。这个设计在实际项目中节省了大量不必要的组件更新且实现成本不过是一个Array.some。2.4 中间件拦截一切状态流转中间件是我整套架构里最得意的一块。调用方可以注册若干函数在reducer执行之前或之后介入。之前主要用于打日志后来发现还可以做权限校验、异步请求埋点、错误上报。中间件的实现并不复杂本质上就是一个函数数组在dispatch流程中按顺序执行type Middleware (context: DispatchContext, next: () void) void; function runMiddlewares(middlewares: Middleware[], context: DispatchContext) { let index 0; const next () { const mw middlewares[index]; if (!mw) return; mw(context, next); }; next(); }这种洋葱圈模型可能有人眼熟但rea的中间件上下文里只包含模型名、动作名、载荷、当前状态和补丁对象没有多余概念。这样中间件可以做得非常纯粹测试也容易。项目里最常用的中间件是一个异步日志器它会记录每个动作前后状态的变化差异并输出到控制台。调复杂bug的时候把日志拉出来对比前后状态基本一眼就能定位问题。3. 实操过程从零搭一个rea应用理论讲再多不如直接上手写一个完整项目。我挑了一个典型场景购物车面板。它包含商品列表、已选数量、总价、优惠码和结算状态状态之间有不少联动关系非常适合演示rea的能力。最终效果是一个原生TS写的页面不依赖任何框架直接用DOM API渲染。3.1 工程初始化与核心接入先用npm初始化一个空的TypeScript工程安装必要的开发依赖。这里选择Vite作为开发服务器因为它的构建速度和热更新体验都很好而且配置几乎为零。npm create vitelatest rea-demo -- --template vanilla-ts cd rea-demo npm install装完之后做两件事第一件是打开tsconfig.json确认strict模式为true第二件是把rea的四个核心文件复制进src/core目录。我自己的项目中rea核心代码包含model.ts、store.ts、subscribe.ts和middleware.ts一共300多行。细节提醒strict模式必须开。后面你会看到如果类型是any泛滥字段级订阅的场景里很可能出现拼写错误导致订阅失效而strict能在编译期帮你兜住一部分低级错误。3.2 定义购物车模型购物车业务域的第一步是定义数据结构和初始值。我列了这么几个字段商品列表、选中的商品ID集合、优惠码、结算状态。初始值都是空或者默认值保证任何时候重置模型都能回到“车是空的”这个原点。// src/models/cart.ts import { defineModel } from ../core/model; export const cartModel defineModel(cart, { items: [ { id: p1, name: 机械键盘, price: 399, count: 1 }, { id: p2, name: 显示器支架, price: 159, count: 2 }, ], selectedIds: [] as string[], promoCode: , status: idle, // idle | checking | success | error });商品列表里的价格和数量是模拟写死的实际项目里这些数据会来自接口。把状态设计成“初始化时为空、使用时填充”还是“初始化时放着默认数据”我的经验是凡是涉及展示型页面初始值尽量接近真实场景这样开发调试时不用每次手动造数据凡是涉及提交型流程初始值一律空避免误用脏数据。3.3 注册reducer与动作状态结构定了接下来注册变更逻辑。我按业务动作拆了一批reducer添加商品、勾选/取消勾选、应用优惠码、设置结算状态。每个reducer只负责一个明确的小动作命名也尽量动词化。import { cartReducer } from ./cartReducer; export const cartActions { addItem: (payload: { id: string; name: string; price: number }) ({ items: pushItem(cartReducer.state, payload), // 简化描述 }), toggleSelect: (payload: { id: string }) { const selected new Set(cartReducer.state.selectedIds); selected.has(payload.id) ? selected.delete(payload.id) : selected.add(payload.id); return { selectedIds: [...selected] }; }, // ... 其他动作 };注意reducer函数不应该直接修改state而是返回补丁对象。这是rea的铁律。补丁对象会被浅合并到当前状态里整个过程不会破坏原对象的引用。这一点对性能优化很重要如果组件通过浅比较来决定是否重新渲染那么不变的部分引用完全一致可以跳过diff。3.4 用订阅驱动DOM更新原生TS项目没有虚拟DOM所以我用一个简单函数把store状态渲染到页面上。页面里有三个主要区域商品列表、选中摘要和结算结果。当任意状态发生变化时重新渲染全部并不划算所以我利用字段级订阅来精确控制更新范围。// src/main.ts import { createStore } from ./core/store; import { cartModel } from ./models/cart; import { cartActions } from ./models/cartActions; const store createStore(); store.register(cartModel, cartActions); // 渲染选中摘要 const renderSummary () { const state store.getState(cart); const total state.selectedIds.reduce((sum, id) { const item state.items.find(it it.id id); return sum (item ? item.price * item.count : 0); }, 0); document.getElementById(summary)!.textContent 已选 ${state.selectedIds.length} 件合计 ¥${total}; }; // 订阅selectedIds字段变化时仅更新摘要区 store.subscribe(cart, renderSummary, [selectedIds]);这段代码里订阅的第三个参数是关键它告诉rea我只需要在选中集合变化时重新计算总价。如果商品单价改了、优惠码变了摘要区的render不会多余执行自然也不会引起无谓的DOM操作。这就是字段级订阅带来的可感知性能提升。3.5 处理异步流程优惠码校验购物车里最容易踩坑的是异步操作。以优惠码校验为例用户输入一串码点击应用后需要请求服务端确认优惠码是否有效期间按钮要置灰完成后要更新最终价格。用rea实现这个流程时我先触发一个status: checking的动作然后发起请求拿到结果后再触发成功或失败的动作。async function applyPromoCode(code: string) { store.dispatch(cart, setStatus, { status: checking }); try { const result await mockRequest(code); if (result.valid) { store.dispatch(cart, applyPromo, { promoCode: code, discount: result.discount }); } else { store.dispatch(cart, setError, { error: 优惠码无效 }); } } finally { store.dispatch(cart, setStatus, { status: result.valid ? success : error }); } }这里要特别强调一点异步操作完成后必须继续走dispatch更新状态不要尝试直接修改仓库里的数据对象。原因很简单如果你绕过了dispatch中间件和订阅链路全部失效页面不会刷新还会留下难以追踪的隐性状态。我在代码里加了一个开发环境的守卫函数直接在store实例上挂一个assertNotFrozen的逻辑每当state被补丁合并后就递归冻结对象任何绕过dispatch修改属性的行为都会在严格模式下抛错。这个操作对性能有点影响但只在开发模式启用收益远大于开销。4. 常见问题与排查实录rea用了快一年实际项目中遇到的坑不少但基本上都能用同一套思路解决。我整理了五个最典型的问题都是真实发生过的场景每个都给出排查步骤和最终方案。4.1 修改了对象但视图不更新这个问题的现象是dispatch执行了日志也打印了页面就是不动。排查后发现绝大多数原因都是reducer直接修改了原state的嵌套对象。比如有人写return { user: { ...state.user, name: new name } };这是正确的。但如果写成state.user.name new name; return {};就有麻烦了。因为浅合并只会对比第一层字段user的引用没有改变订阅器自然认为没有变化。解决方式有两个一是严格执行“不修改原状态返回新对象”的规范二是在订阅触发时不做浅比较而是做深度比较但深度比较性能代价高所以我只在开发模式开启。4.2 异步竞态导致最终状态错乱这是最隐蔽的坑之一。场景是这样的用户在搜索框里快速输入每输入一个字就触发一次异步请求。结果A请求比B请求晚发出但先返回了页面显示的内容就来自旧请求。后来我加了请求序号作为守卫每次请求发出前递增计数器回包后比较序号只有最大序号的请求才允许进入状态更新。这个方案反应快且实现成本低。let requestSeq 0; async function search(keyword: string) { const seq requestSeq; const result await mockRequest(keyword); if (seq ! requestSeq) return; // 过期响应直接丢弃 store.dispatch(search, setResult, result); }这个方法简单得让人不敢置信但它确实解决了我项目里90%以上的竞态问题。更复杂的场景可以引入AbortController但对大多数业务来说序号守卫已经足够。4.3 内存泄漏订阅回调越积越多有段时间页面上某些组件会越跑越慢浏览器最终甚至会卡死。用性能分析工具一看监听器数量爆炸了。原因特别低级组件每次挂载都会调用subscribe但在卸载时忘记了调用返回值里的取消函数。后来我学乖了把subscribe的返回值设计成销毁器在组件卸载时统一调用。如果你的工程是React还可以封装一个useReaSubscription的钩子内部用useEffect返回清理函数从根源上杜绝泄漏。4.4 性能瓶颈大列表里每个项目都订阅电商后台有那种一次性渲染几百个商品卡片的大列表每个卡片里的选择状态都要和全局store同步。如果每个卡片都单独订阅全局字段会造成大量无效回调。我优化成“只订阅可见区域”的模式列表区只订阅一个visibleRange字段滚动时通过变换range来触发渲染卡片本身不直接订阅store。这个改动让长列表的内存占用量直接降了四成滚动流畅度也有了质的提升。把“每一个小部件都有全局状态”变成“区域持有状态、部件只渲染”这个思路不仅适用于rea也适用于任何前端状态方案。4.5 中间件顺序混乱导致日志不完整加中间件时有一次把日志中间件放在了错误处理中间件之后结果错误发生的时候日志反而记录不到。这促使我制定了中间件注册规范打日志类中间件永远排在最外层错误处理靠内层最后才是核心业务中间件。因为洋葱模型的执行顺序决定了外层中间件最先拿到context、最后拿到结束信号所以日志放在外层能看到最完整的链路。这个规范后来被我写进了团队的前端代码规范文档里。中间件这一层能做的远比打日志多还有团队拿它做无侵入埋点服务端状态都在这一层给收口了后续接分析平台只需要加一段适配代码业务代码一行都不用动。5. 项目扩展与生态思考rea目前已经是一个可以实际使用的内核但我经常被问到它能不能做更多事情。其实把核心逻辑往上叠并不难真正难的是保持这套架构的纯粹性。每次想加东西我都先问自己三个问题这是不是所有业务域都需要的通用能力如果放在业务层能解决是不是其实不该进核心这个能力会不会逼迫使用方改变原有的写法基于这个原则我梳理了两个目前觉得值得做、但还没做进核心的功能持久化和跨标签页同步。持久化很直观把store状态的变化订阅下来节流后写入localStorage应用启动时读取并注册为初始值。跨标签页同步本质上是同一套操作日志在不同页面的广播用BroadcastChannel接上就能跑。这两个功能都能以中间件的形式实现代码量不大但放进主仓库反而会让初学者困惑所以我选择把它们作为扩展包维护。另外如果有人想把rea接进React我自己常用的适配方式是写一个useStore钩子内部用useSyncExternalStore把store变化映射为组件重新渲染。这样写的好处是完全不用改动核心代码适配层只有四五行。import { useSyncExternalStore } from react; export function useStore(store, modelName, fieldSelector) { return useSyncExternalStore( (callback) store.subscribe(modelName, callback, fieldSelector), () store.getState(modelName) ); }这也再次印证了前面说的核心越薄生态越容易扩展。最后再分享一个我在实际运维中最受益的小习惯给每个store模型写一个单元测试文件把关键的reducer流转用表驱动的方式测一遍。rea的reducer是纯函数测试起来非常舒服不需要mock任何东西。每次重构核心代码后跑一圈测试底色立刻就看得到。说真的这么薄的一个状态层最大的敌人不是功能缺失而是开发者在“图方便”的念头下不断往核心塞东西。守住“小而稳”的边界这套方案的长期价值才会真正体现出来。