1. 项目概述老读者知道我有个习惯项目做多了以后会顺手把一些反复用到的代码沉淀成自己的工具库。这次想聊的“rea”就是这样一个从实际业务里长出来的小项目。它不复杂也没有炫酷的架构但解决了一个非常具体、非常痛的日常问题——在 React 项目里如何用最小的成本实现跨组件状态同步同时还不用忍受各种重型状态管理库带来的心智负担和样板代码。“rea”本质上是一个基于 React 的状态管理工具集核心依赖只有一行原生 Hook——useSyncExternalStore。它提供了一套极简的 API 来创建、订阅和更新全局或局部的共享状态同时支持按需订阅也就是常说的 selector 模式。如果你的项目规模不大、团队成员对 TypeScript 有要求、又希望状态层的代码足够干净直观那这个小工具很可能比 Redux 或 MobX 更贴合你的实际需求。我把它放到了团队内部的项目脚手架里前前后后落地了几个中后台系统和一个移动端 H5 应用整体表现很稳定。整篇内容我会从设计思路、核心 API 的实现细节、实操过程中的踩坑记录以及常见问题排查几个角度展开方便你拿回去对照着自己实现一套或者直接基于我的思路改造一把。最后会附上一些关于性能优化和长期维护的实用建议——这些都是在真实业务环境里跑过之后才沉淀下来的经验。2. 整体设计与思路拆解2.1 为什么要自己写一套状态管理先坦白一个背景之所以动手写“rea”并不是因为 Redux 不好用而是团队在实际踩了很多次坑之后发现重型状态管理库带来的成本在某些场景下不成比例。典型的问题有三个一是模板代码太多。定义一个异步 action、处理 loading 状态、维护 reducer、补上对应的类型定义整套流程走下来一个简单的请求动作可能要写五六个文件。对一个小型团队来说这个维护负担相当重。二是性能优化需要额外心智。Redux 本身是不做按需订阅的只要 store 里有任何一个 slice 变化所有连接过的组件都会执行一遍 selector 计算。为了规避这个问题又得引入reselect之类的缓存库或者花大量精力去手工拆分状态切片。稍有不慎一个组件就跟着无关状态一起重渲染。三是全局状态和局部状态之间缺少一个自然的过渡带。很多状态其实只是页面内部的跨组件通信放在全局 store 里太浪费放在 Context 里又容易引起整棵子树的级联重渲染。我需要的是一套轻量的方案它兼顾全局和局部两种场景API 足够少类型推导足够强并且能够天然支持 selector 订阅——也就是组件按需消费 store 中与自己相关的部分无关变动完全不触发重渲染。这就是“rea”最初的定位。2.2 为什么最终选定 useSyncExternalStoreReact 官方其实很早就意识到外部状态订阅是一个普遍需求。在 React 18 之前开发者只能自己用useEffect加useState来模拟订阅行为这带来一个危险的问题外部 store 的更新可能发生在渲染阶段之前如果此时读取的状态和渲染读取的状态不一致就会出现“撕裂”tearing现象导致 UI 显示旧值、交互用的是新值结果界面和逻辑互相矛盾。React 18 之后官方提供了useSyncExternalStore这个 Hook它把“订阅外部数据源”这件事标准化了。组件通过它订阅 store 的快照React 会在并发渲染期间自动检查快照是否一致如果发现不一致会重新渲染一次来保证视觉和逻辑的同步。这意味着我不需要再自己操心并发模式下的边界情况“rea”只需要负责两件事维护一个状态容器对外暴露 subscribe、getSnapshot 两个方法然后交给 React 处理剩下的调度。这个选择还有一个额外的优势它就是 React 官方推荐的外部数据订阅方式跟 React 核心团队的长期设计方向保持了一致将来即便升级 React 版本这一层也不太会遭到破坏。3. 核心 API 设计与实操要点3.1 最小的状态容器应该长什么样先给“rea”定义一个最核心的容器对象。它不需要有任何框架代码只需要是一个普通的闭包或对象里面保存当前状态并且提供订阅和读取能力。这个底层设计直接决定了整套工具的天花板所以务必想清楚。我采用的对象结构大致是这样的type Listener () void; export interface StoreS { getState: () S; setState: (partial: PartialS | S) void; subscribe: (listener: Listener) () void; }getState负责返回当前状态快照。setState负责合并更新。subscribe则是注册一个监听函数任何状态变更都会触发它。这里有一个设计决策值得说一下我刻意没有把subscribe的参数设计成直接接收新旧值而是采用最简单的“无参回调”。这样做的原因是订阅方通常只关心“我要重新读取数据”具体怎么读取、读取哪一部分由订阅方自己决定。这种设计让 store 层变得无比纯粹也方便以后扩展中间件。紧接着是核心逻辑——一个微型发布订阅器export function createStoreS extends Recordstring, unknown( initialState: S ): StoreS { let state: S initialState; const listeners new SetListener(); const getState () state; const setState (partial: PartialS | S) { const nextState typeof partial function ? (partial as (prev: S) S)(state) : partial; state Object.assign({}, state, nextState); listeners.forEach((listener) listener()); }; const subscribe (listener: Listener) { listeners.add(listener); return () listeners.delete(listener); }; return { getState, setState, subscribe }; }这里的setState我故意支持两种传参方式传一个局部对象或者传一个函数。函数式写法的好处是可以在连续多次更新时拿到最新的状态值避免闭包捕获旧值。listeners用Set而不建议用数组因为删除监听器的时间复杂度更低而且天然去重。3.2 useStore 与按需订阅的封装容器搞定了下一步是把它接到 React 上。这里最核心的封装是一个useStoreHook它接受一个 store 实例和一个 selector 函数。selector 的作用是从整个全局状态中挑出当前组件关心的部分。关键实现如下import { useSyncExternalStore } from react; export function useStoreS, U( store: StoreS, selector: (state: S) U ): U { const getSnapshot () selector(store.getState()); return useSyncExternalStore( store.subscribe, getSnapshot, () getSnapshot() ); }useSyncExternalStore接收三个参数subscribe 函数、getSnapshot 函数和 getServerSnapshot 函数。第三个参数只在服务端渲染或生成静态页面时才用得到大多数客户端项目可以复用同一个快照函数。需要注意的是getSnapshot必须保证返回值的引用稳定。如果 selector 内部每次都返回一个新创建的对象比如直接返回{ name: state.user.name }React 会认为快照发生了变化从而触发死循环渲染。这是一个新手必踩的坑后面我会给出对应的规避方案。3.3 中间件与异步 action 的处理实际业务里状态管理不可能只处理同步的赋值操作。我们需要处理异步请求、loading 状态、错误捕获。为了不让 store 的核心逻辑过度膨胀我给“rea”设计了一个非常简单的中间件机制。中间件本质上就是对setState的包装。比如一个记录日志的中间件可以这样写function loggerS(store: StoreS) { const originalSetState store.setState; store.setState (partial) { console.log(prev state:, store.getState()); originalSetState(partial); console.log(next state:, store.getState()); }; }异步 action 则是直接基于函数式setState来做的。比如一个模拟的请求场景const store createStore({ loading: false, data: null, error: null }); async function fetchData() { store.setState({ loading: true, error: null }); try { const data await request(/api/list); store.setState({ loading: false, data }); } catch (error) { store.setState({ loading: false, error }); } }这套方案没有引入 thunk 之类的额外概念因为函数式 setState 已经足够表达异步流程了。在组件里只需要通过useStore取到状态在事件回调里调用fetchData即可。整个数据流非常直白排查问题时也不需要在多个文件之间来回跳转。4. 实操过程与核心环节实现4.1 创建自定义 Hook 时的类型推导TypeScript 的支持程度决定了一个状态管理库能不能被团队真正采用。“rea”在类型推导上做了两个关键设计第一个是 store 的状态类型可以从createStore的初始值自动推断出来不需要额外声明泛型第二个是 selector 的类型天然透传到组件里。具体使用效果是这样的const useUserStore () { return { store, userInfo: useStore(store, (state) state.userInfo), }; };这里userInfo的类型会自动推导为初始值中userInfo的类型。如果初始值里没有定义某个字段TypeScript 会在编译期直接报错根本等不到运行时才发现问题。对团队来说这相当于把一部分代码检查前置到了编辑器里长期收益非常明显。如果要进一步优化性能还可以给useStore增加一个浅比较缓存层。React 官方的useSyncExternalStore并不默认做相等性判断所以当 selector 返回一个新对象时即使内容没变也会触发重渲染。常见的做法是维护一个 WeakMap 缓存键为 selector 函数值为上一次返回的快照对象每次执行时先浅比较一下内部字段完全相同就直接返回上一次的引用。4.2 全局状态和页面级状态的划分实践在实际项目中我不会把所有状态都塞进一个全局 store。一个健康的架构应该是“全局 store 只放跨页面共享的少部分状态页面级状态用局部 store 管理”。我一般会遵循以下三个原则跨路由共享的数据放入全局 store比如用户登录信息、系统权限、全局的 UI 设置。单个页面内多个组件共享的数据用页面内的局部 store 管理不污染全局。完全私有的组件状态先用useState真的出现多组件通信时再升格为局部 store。以一个典型的列表页为例页面顶部的筛选区、中间的表格区、底部的分页区这三个组件共享筛选条件、分页页码和数据列表。如果不用全局 store每处都要通过 props 层层传递改动起来非常痛苦。但如果把这些状态放进全局 store又会在离开页面后残留数据影响下一次进入时的展示。局部 store 正好填上了这个空档。实现上局部 store 的创建和销毁跟随组件生命周期通常用useRef结合懒初始化来做function useLocalStoreS(factory: () StoreS) { const ref useRefStoreS | null(null); if (!ref.current) { ref.current factory(); } return ref.current; }这样每次进入页面都是全新的状态离开页面后自动被垃圾回收不需要手动清理。4.3 持久化中间件的完整实现除了日志我在实际项目中用得最多的是持久化中间件。比如用户偏好设置、购物车等状态需要同步到localStorage刷新后还能恢复。这个实现不复杂但有几个细节值得注意。function persistS extends Recordstring, unknown( store: StoreS, options: { key: string; partial?: (keyof S)[] } ) { const cached localStorage.getItem(options.key); if (cached) { try { const parsed JSON.parse(cached); store.setState(parsed); } catch (e) { localStorage.removeItem(options.key); } } const originalSetState store.setState; store.setState (partial) { originalSetState(partial); const state store.getState(); const toSave options.partial ? options.partial.reduce((acc, key) { return { ...acc, [key]: state[key] }; }, {}) : state; localStorage.setItem(options.key, JSON.stringify(toSave)); }; }这里有两个重要细节第一读取缓存时外面一定要包一层try/catch因为localStorage里的数据格式可能被用户或第三方脚本修改过JSON.parse 可能直接抛异常第二建议使用partial参数指定需要持久化的字段不要默认把整个状态都塞进去否则可能把一些临时性的 UI 状态也一起存起来导致刷新后出现莫名其妙的残留。5. 常见问题与排查技巧实录5.1 getSnapshot 返回值导致死循环这是我最初使用useSyncExternalStore时遇到的头号问题。当时的代码是这样的const snapshot useStore(store, (state) ({ name: state.user.name, age: state.user.age, }));每次执行 selector 都会生成一个新的对象React 在做快照比较时发现引用不同于是立刻重渲染重渲染时又生成新对象结果直接卡死页面。排查方法很简单把 this.setState 逻辑停掉在 selector 里加一个 console.log如果发现它在不停打印就说明快照函数返回值不稳定。现在我的规范是selector 只返回原始值比如state.user.name这个字符串确实需要组装对象时用默认参数加shallowEqual手写一个浅比较的缓存层。注意不要依赖JSON.stringify做比较因为对象字段顺序可能有变动而且性能更差。5.2 订阅泄漏导致的内存异常如果你在快速切换路由时觉得页面越来越卡大概率是 store 的订阅者没有正确销毁。useSyncExternalStore本身会在组件卸载时自动调用 subscribe 返回的取消函数但如果你的代码里手动store.subscribe了一定要记得在useEffect的清理函数里调用取消函数。一个常见的错误是useEffect(() { store.subscribe(() console.log(state changed)); }, []);这段代码的问题在于 subscribe 返回的取消函数被丢弃了。正确的写法是useEffect(() { const unsubscribe store.subscribe(() console.log(state changed)); return unsubscribe; }, []);5.3 异步更新中的闭包陷阱使用函数式 setState 时如果业务代码里用了外部变量很容易踩闭包陷阱。举例来说function handleSubmit(userId: string) { store.setState((state) { const list state.list.map((item) item.id userId ? { ...item, submitted: true } : item ); return { list }; }); }这段代码在绝大多数场景下是安全的但如果你在同一个事件循环里连续触发多次 submit并且每次的 userId 都一样第二次执行时拿到的 state 可能是更新后的。这个场景下建议尽量从状态内部取数而不是依赖外部闭包。状态管理本质上统一了数据来源所以每次更新都尽量基于 store 当前值推导而不是基于渲染闭包里的旧值。5.4 常见问题速查表问题表现可能原因排查思路页面卡死、CPU 飙高selector 返回新引用在 selector 内打印日志确认是否无限循环切换路由后状态残留用了全局 store 存页面级状态改成局部 store或手动重置状态刷新后数据丢失持久化中间件未启用或 key 错误检查 localStorage 中是否有对应 key多组件状态不同步组件各自创建了独立 store 实例确认是否共用了同一个 store 引用类型推导失败初始值里缺少字段定义显式声明泛型参数或补全初始值6. 性能调优与长期维护建议状态管理库的长期维护真正困难的不是写功能而是保证架构不会随着项目膨胀而腐烂。“rea”在落地过程中我也沉淀了几条特别值得分享的约束和技巧。第一条约束是永远不要把非序列化的东西放进 store。函数、DOM 节点、Date 实例这类对象一旦放进状态持久化和调试都会变得非常麻烦。如果你确实需要存放临时对象最好单独拆一个字段并且注明不清洗。第二条约束是selector 必须保持纯粹。不要在 selector 里做数据变换、过滤或排序之类的操作。这些操作应该放在数据进入 store 前或者使用独立的 memoized 函数来处理。否则每次状态变化时即使组件本身只依赖一个小字段也可能因为父级重渲染连带重新执行所有子级 selector造成隐性浪费。第三条经验是关于状态更新的粒度。我建议将业务状态按“领域模型”拆分而不是按“页面需求”拆分。比如用户信息聚合在一个 store、订单聚合在另一个 store。这样即使页面结构后续变动很大状态层也不会跟着重新设计。第四条是关于调试体验。由于“rea”的核心实现只有一百多行代码所有逻辑都是透明的出了问题可以直接在源码里定位。相比黑盒的第三方库这种透明性在团队协作时特别有价值。新同学上手时把 store 源码读懂基本就和核心逻辑同步了。我现在还在持续迭代这个小工具下一步准备给它加上可选的 devtools 支持让时间旅行调试也能在轻量框架下体验。如果你也在设计自己的状态管理层希望这篇文章里关于 selector 稳定性、订阅清理、中间件扩展和类型推导的经验能帮你少走一些弯路。这些细节基本都是要在真实业务里摔过几次跟头才能意识到的。