如果你也遇到过这样的场景：项目里十几个组件各自维护定时器刷新同一个数据源，最后改一个字段，别的模块要么纹丝不动，要么集体抖动，那你八成需要把状态层彻底重写一遍。我负责的一个数据可视化 Demo 就栽在过这种问题上，最后的解法是我们内部封装了一个代号 rea 的响应式数据层。它不是什么花哨的框架，核心就是两件事：声明状态、让依赖状态的计算自动重跑。这篇文章不打算写使用文档式的冷静介绍，而是把我从设计、接入、踩坑到调优的完整经历摊开来讲，你如果也在做中后台、数据大屏这类强交互项目，应该能直接拿走一半经验。

1. 初识 rea：一个被线上故障逼出来的内部小库

1.1 那次改个下拉框，整页卡了十秒的教训

事情要从一个很普通的筛选功能说起。页面顶部放了一个城市下拉框，选择“上海”后，按理说下方的订单表格、统计卡片、地图模块应该一起刷新。但上线后第一周就出问题了：切换城市时，统计卡先跳到新数据，表格还停在旧数据，地图上的标记又是另一套结果，整个页面看起来像三个不同时间的截图拼在一起。更离谱的是，连续切换几次筛选条件，页面会直接卡顿十秒左右。

这个故障持续了几天，我们一度怀疑是后端接口慢。后来在浏览器 Performance 面板里逐段排查，才发现崩溃点全在前端：代码里没有一个统一的状态源，而是十几个模块各自维护自己的副本。有人用全局对象直接写，有人在组件内部useState存了一份，还有人在事件总线上反复监听同一批事件。筛选器一变，几乎每段代码都收到通知，又各自去拉接口，最后竞态条件把整个页面状态搅成一锅粥。

当时我的第一反应不是去补一个“状态同步工具”，而是把整条数据链路拆出来重新设计。我们花了大约两天半的时间，在项目里抽了一个很小的数据层，代号就叫 rea。它的目标很明确：让“谁修改了数据”和“谁依赖了数据”这两件事变得完全透明。

1.2 rea 解决的三个问题

rea 之所以在我们内部能活下来，是因为它正面解决了三个看起来简单、实操里却很痛的问题：

第一，状态变更不可追踪。以前想查“这个数字到底是谁改的”，几乎要靠全局搜索赋值语句。rea 把所有修改都收敛到几个写函数上，配合调试钩子，能直接看到某一字段的触发来源。

第二，视图与数据耦合太深。组件里到处是手动触发的刷新逻辑，数据一变就要考虑“哪个组件需要重渲染”。rea 把数据层独立出来，组件只负责订阅自己真正用到的字段，剩下的联动由依赖关系自动完成。

第三，跨模块通信成本太高。事件总线的核心痛点是：订阅容易、退订容易漏、定位难。rea 的依赖收集是自动的，effect 执行完就建立连接，不需要人工维护监听器列表。

rea 的完整 API 并不复杂，核心就四类：

后来某个版本又加了一个createStore便捷封装，用来处理对象形态的 multi-field 状态，但核心心智模型始终没变：读时收集依赖，写时精准通知。

1.3 适合读到这篇文章的人

如果你是纯静态页面开发者，其实不需要 rea，一个useState足够跑十年。但如果你正在做以下事情，这篇文章应该对你有用：

• 中后台系统里有大量“筛选器 + 表格 + 统计卡片”的级联联动；
• 多个模块需要共享同一份实时变化的数据，比如大屏指标、协作光标、聊天列表；
• 你在维护一个核心业务对象，却被事件总线或全局变量整得焦头烂额；
• 你想深入了解 Signal 这类响应式数据方案到底是怎么工作的。

这篇文章不会教你背 API，重点讲原理和取舍。我尽量把当时踩过的每一个坑都还原出来，你遇到类似现象时可以直接对号入座。

2. rea 的响应式内核说到底是一张“借书登记表”

2.1 从发布订阅到信号机制，为什么换了思路

在 rea 之前，我们惯用的方案是事件总线：某个模块修改了筛选条件，就emit('cityChanged')，其他模块各自on('cityChanged', handler)。听起来很合理，但实际维护起来完全不是那么回事。它本质上是一种广播模型，不管监听者是不是真的需要这份数据，只要注册了就会收到通知。就像小区装了广播大喇叭，不管家里有没有人，永远对着整栋楼喊一遍，结果是大量空跑和误触发。

Signal 的机制完全不同。它把“读取”这件事变成了一次显式的登记。你可以把它想象成图书馆的借书登记表：每次有代码读取某个信号值，rea 就把“哪段代码借走了这个值”记录到一张表里；当这个信号后续变化时，系统只通知那些真正借过这本书的人。

这样做带来的最大收益是确定性。不再需要手动维护“谁该听谁的消息”，因为依赖关系是运行时自动建立的。你只需要保证一件事：在 effect 回调里老老实实通过信号读取数据，其它的交给 rea 处理。

2.2 createSignal 与 createEffect 的最小实现

为了把原理讲透，我整理了一个教学版实现。它不是 rea 的完整代码，少了调度优化和边界清理，但能让你看清读时收集、改时派发的核心逻辑：

let activeEffect = null export function createSignal(initialValue) { let value = initialValue const consumers = new Set() const read = () => { if (activeEffect) { consumers.add(activeEffect) activeEffect.deps.add(consumers) } return value } const write = (nextValue) => { if (Object.is(value, nextValue)) return value = nextValue ;[...consumers].forEach((effect) => effect()) } return [read, write] } export function createEffect(fn) { const effect = () => { if (effect.deps) { for (const deps of effect.deps) deps.delete(effect) } const prev = activeEffect activeEffect = effect effect.deps = new Set() try { fn() } finally { activeEffect = prev } } effect() return () => { for (const deps of effect.deps) deps.delete(effect) } }

这个版本最关键的是全局变量activeEffect。当一个 effect 执行时，activeEffect会指向它自己；effect 内部读取 signal，就自动把自己加入这个信号的消费者列表。一旦 signal 被写入新值，所有登记过的 effect 都会被重新执行。

这里有个设计取舍：依赖清理。效果重跑之前，要把自己从旧依赖集合里移除，否则依赖变化后还在继续通知一个已经“过期”的 effect。上面代码里effect()每次执行第一件事就是清理旧依赖，这是很多人手写响应式系统最容易漏掉的一步。

2.3 为什么 rea 需要一层调度器来“踩刹车”

教学版本里，write是同步触发所有 effect 的。这在简单场景下没问题，但真实项目里会引发三个连锁问题：

首先是递归更新。一个 effect 内部修改了一个已经被自己依赖的信号，就会触发自身无限循环。

其次是重复渲染。一次交互里往往连续修改好几个信号，每个信号同步触发一批 effect，会导致 UI 在同一帧里反复更新多次。

第三是中间态泄露。你修改了一个状态的前置条件，还没改后续状态，此时 effect 已经执行了一次，外部看到的数据是前后不一致的。

rea 的解法是给所有 effect 加一层调度器：把触发任务放进一个队列，用微任务统一冲刷。同一个 effect 在同一次事件循环里不管被加入多少次，最终只执行一次：

let scheduled = false const jobQueue = new Set() function scheduleEffect(effect) { jobQueue.add(effect) if (scheduled) return scheduled = true Promise.resolve().then(() => { scheduled = false const jobs = [...jobQueue] jobQueue.clear() jobs.forEach((job) => job()) }) }

这个调度器就是批量更新的本质。你在一次同步操作里改了十个信号，这十个信号的消费者会被放进同一个 job 队列，然后在一个微任务里统一跑完，UI 只刷新一次。

3. 接入数据大屏 Demo：从频繁抖动到丝滑联动

3.1 工程化接入与目录结构

rea 最开始是从源码直接引用的内部库，并没有急着发布成独立包。我们的做法是在项目里建一个src/lib/rea.js，把核心逻辑放在里面，业务代码再通过统一入口引用。目录结构大致是这样的：

src/ lib/ rea.js stores/ dashboard.js components/ FilterBar.jsx OrderTable.jsx StatCards.jsx

把数据层独立成stores目录，而不是散落在各个组件里，是后续能顺利排查问题的关键。哪怕只是一个小项目，也建议在一开始就划清边界：组件里只保留视图逻辑，所有跨模块共享的数据全部进 store。

3.2 建模：筛选项、表格数据与派生结果

这个 Demo 的核心业务是订单数据看板。按照 rea 的思维模型，我把它拆成了三块：

• 原始数据：后端返回的订单全量数组。
• 交互状态：当前选中的城市、每页条数。
• 派生数据：筛选后的可见订单列表、统计卡片所需的汇总金额。

建模结果如下：

// stores/dashboard.js import { createSignal, createEffect, createMemo, } from '../lib/rea' const [city, setCity] = createSignal('全部') const [pageSize, setPageSize] = createSignal(20) const [orders, setOrders] = createSignal([]) const [loading, setLoading] = createSignal(false) export const visibleOrders = createMemo(() => { const list = orders() const currentCity = city() if (currentCity === '全部') return list return list.filter((item) => item.city === currentCity) }) export const totalAmount = createMemo(() => { return visibleOrders().reduce((sum, item) => sum + item.amount, 0) }) export const dashboardStore = { city, setCity, pageSize, setPageSize, orders, setOrders, loading, setLoading, }

注意看这三个信号的关系：orders是原始数据，city是筛选条件，visibleOrders是由它们推导出来的结果。整个 store 里没有一行“通知列表去刷新”的代码，因为刷新动作完全由依赖机制驱动。

3.3 组件按需订阅，不再关心谁改了数据

在 React 里接入 rea 时，我建议用useSyncExternalStore这个官方 Hook 来做桥接。它的subscribe参数需要接收一个订阅函数并返回取消订阅函数，rea 的createEffect返回值正好就是 dispose 函数，天然契合：

import { useSyncExternalStore } from 'react' import { createEffect } from '../lib/rea' export function useRea(getter) { return useSyncExternalStore( (callback) => createEffect(() => { getter() callback() }), getter, getter ) }

组件里用起来就很干净：

function OrderTable() { const rows = useRea(visibleOrders) return ( <table> {rows.map((order) => ( <tr key={order.id}> <td>{order.city}</td> <td>{order.amount}</td> </tr> ))} </table> ) }

useRea每次订阅时只读取visibleOrders()，不会去读pageSize或orders本身，所以只有当筛选结果真正变化时，这个组件才会重新渲染。这种按需订阅的模式，从业界经验来看是最不容易出现“牵一发动全身”的写法。

3.4 为什么先把状态定义在组件外面很重要

刚开始使用 rea 的时候，有同事图方便，直接在组件函数内部创建信号：

function BadExample() { const count = createSignal(0) // 不行，组件卸载状态就没了 // ... }

这几乎一定会出问题。组件一旦卸载，信号实例就被垃圾回收，再回来时数据已经丢光。rea 里共享状态的生命周期应该跟随应用或页面，而不是跟随某个组件。

正确的做法是把信号定义在组件外部的 store 模块里，通过 getter 函数暴露给组件。如果确实有“只属于某个组件”的临时状态，那说明它本来就不应该放进 rea，直接用 React 的useState反而更合适。

4. 三个真实踩坑：依赖丢失、异步竞态、循环触发

4.1 坑一：解构出来的状态“不活”了

在引入createStore之后，我们遇到第一个严重问题是：某个组件订阅的 store 字段永远不变了。

当时项目里有一个全局的配置对象，我们把它包进了createStore。代码大致长这样：

const configStore = createStore({ theme: 'dark', locale: 'zh-CN', }) const { theme } = configStore createEffect(() => { console.log(theme) }) configStore.theme = 'light'

控制台只输出了一次dark，再怎么改 configStore 都不会触发 effect。

排查过程是这样的：我先重新读了一遍代码，发现变量theme是在 effect 外部通过解构拿到的。此时 Proxy 的get陷阱已经被触发过一次，解构拿到的是当时字符串值'dark'，它本身是一个普通字符串，没有任何依赖追踪能力。之后 effect 内部读取的theme实际上是一个固定字符串，自然也不会建立依赖关系。

修复方式很简单：

createEffect(() => { console.log(configStore.theme) })

类似问题也会发生在把 store 对象深拷贝后传给子组件的场景。记住一个原则：经过 createStore 包装的响应式对象，传递时永远传代理本身，不要中途拆下来传“值”。如果你想要按字段共享，更稳的方案依旧是 createSignal。

4.2 坑二：effect 里发异步请求，后续依赖不再收集

这个坑非常隐蔽，它藏在一个看起来很合理的异步加载代码里：

createEffect(async () => { const currentCity = city() const rows = await fetchOrders(currentCity) const size = pageSize() // 这里读 pageSize 并不会被收集为依赖 orders.set(rows.slice(0, size)) })

从直觉上看，这个 effect 既读取了city()，又读取了pageSize()，似乎两者变化都应该触发它重新执行。实际上，响应式依赖收集是同步的，它只发生在异步函数执行到await之前的那段同步代码里。pageSize()是在 await 之后的回调里读取的，此时activeEffect已经被恢复成 null，rea 根本不知道这个 effect 依赖了pageSize。

结果是：切城市能刷新表格，但调整每页条数时表格毫无反应。

根治的方法是让 effect 同步读取所有依赖，再在内部启动异步流程：

createEffect(() => { const currentCity = city() const size = pageSize() void fetchOrders({ city: currentCity, pageSize: size }).then((rows) => { orders.set(rows.slice(0, size)) }) })

虽然fetchOrders(...).then是异步的，但city()和pageSize()都在同步段被调用，依赖收集已经完全建立。

如果你已经用了 rea 这类支持 onCleanup 的规格，最好再加上竞态取消。否则快速切换城市时，两个请求的响应会互相覆盖：

createEffect((onCleanup) => { let canceled = false onCleanup(() => { canceled = true }) const currentCity = city() const size = pageSize() void fetchOrders({ city: currentCity, pageSize: size }).then((rows) => { if (canceled) return orders.set(rows.slice(0, size)) }) })

我把这个规则总结成了一句口头禅：异步流程可以放到 effect 外面，但依赖读取必须放到 effect 的同步执行阶段。

4.3 坑三：两个 effect 互相修改导致死循环

还有一个让人印象深刻的现场：某天页面突然卡死，打开控制台发现浏览器直接报了 “Maximum call stack size exceeded”。

定位下去，根因是两个 effect 形成了闭环：

createEffect(() => { a.set(b() + 1) }) createEffect(() => { b.set(a() + 1) })

a变化触发第一个 effect，第一个 effect 修改b；b变化触发第二个 effect，第二个 effect 又修改a。两个 effect 不断互相唤醒，即使调度器做过去重，也只是保证了同一批任务不会重复入队，并不能终止两个 effect 之间的循环唤醒。

当时我的排查链路是这样走的：

1. 先用 Performance 面板记录页面卡顿期间的长任务，确定为持续脚本执行；
2. 在疑似 effect 回调的第一行加console.log('effectA')和console.log('effectB')，发现两个日志交替打印，瞬间确认循环；
3. 临时把其中一个 effect 用dispose停掉，卡顿消失，反向验证了因果链；
4. 最后重构数据模型，把交互状态抽成单一事实来源，用 createMemo 表达派生关系。

重构后的形态是：

const base = createSignal(0) const a = createMemo(() => base() + 1) const b = createMemo(() => base() - 1)

这样数据流从base单向发散到a和b，它们都只读不写，天然不会成环。

4.4 定位响应式问题的三个手动工具

踩过几次坑之后，我总结出三个应对响应式问题的土办法，它们不依赖复杂调试工具，但很快能缩小范围：

第一个是给 effect 起名字。rea 内部支持在开发模式下给 effect 打上 name 标签，任何一次写入都会打印触发链条。如果没有现成能力，手动在回调里第一行打日志也足够。

第二个是查看某个信号的消费者列表。我们在调试版 rea 里给每个 signal 暴露了一个非标准方法consumers()，它返回当前登记了哪些 effect。当你怀疑某个 effect 没有更新时，直接查看它是否还在消费者列表里即可。

第三个是临时替换法。把疑似问题 effect 改成setTimeout(() => ...)延迟执行，如果不再复现 bug，说明问题出在依赖收集时机；如果依旧复现，那大概率是业务逻辑本身的问题，跟响应式系统无关。

5. 性能调优：批量更新、调度时机与代理边界

5.1 为什么“改一个字段，所有界面都跟着刷了一遍”

接入 rea 几个月后，我们遇到了一个看似离谱的性能问题：修改城市后，整个页面所有组件都重渲染了一遍。

一开始我以为是调度器的问题，后来发现原因是组件订阅粒度太粗。我们在某个组件里这么写了：

function DashboardPage() { const state = useRea(() => dashboardStore) // 读取整个 store，等于订阅了所有字段 }

这个 getter 每次执行都会读取dashboardStore对象本身。rea 无法判断你到底需要哪个字段，因为代理的 get 陷阱在读取对象这一层就已经被触发了，于是所有字段都被记作依赖。结果就是任何信号变化都会通知这个组件。

修法很简单：让 getter 只返回组件真正用到的数据。比如统计卡只订阅totalAmount()，表格只订阅visibleOrders()。依赖收集越精准，无关渲染越少。

5.2 调度器与 batch 到底解决了什么

调度器的价值前面说过：同一轮微任务里多次写信号，只会触发一次 effect 执行。那么在已经有调度的前提下，batch还有存在的必要吗？

有，但场景比想象中窄。默认的微任务调度只能覆盖“同步代码块内多次写入”。如果你在 effect 执行过程中修改了多个信号，而这些信号又分别触发了其他 effect，中间态仍然可能影响外部观察者。batch可以让整个事务期间的写入全部延后通知：

import { batch } from 'rea' batch(() => { store.a = 1 store.b = 2 })

我们做画布拖拽时发现，如果没有 batch，拖拽过程中每移动一像素都会产生两三次派生计算，体感上明显“黏滞”。包进 batch 之后，一次拖拽事件只做一次完整的状态提交。这个场景里 batch 的价值是很实在的。

5.3 别把低频字段塞进响应式系统

性能调优到后期，我意识到一个反直觉的点：响应式并不是“越多越好”。某些字段被放进 store 后每次读取都要经过 Proxy 或依赖表查询，如果这些字段很少参与联动，收益为零，开销却是实实在在的。

典型反例是我们把一份静态白名单也放进了 createStore。这份配置有几百条，只在初始化时读一次，结果每次初始化都要构建一堆追踪结构，纯属浪费。

我的判断标准很简单：一个字段如果同时满足“会被多个模块读取”和“会被动态修改”，才值得进入 rea。只读静态配置、初始化后不再变化的数据、组件内部 UI 临时状态，都不应该塞进响应式数据层。

6. rea 适合什么场景，不适合什么场景

6.1 我眼中适合 rea 的三类数据

实际用下来，rea 在前台三类数据场景里收益最大：

第一类是高频小数据联动。比如表格筛选条件、排序字段、分页页码之间的相互影响，Signal 的细粒度通知特性让这些联动变得廉价且可预测。

第二类是跨组件实时共享。数据大屏、聊天消息列表、画布协作这类场景，多个组件需要看到同一份持续变化的数据。如果把状态放在某个组件内部，必然面临数据搬运问题，而放在 rea store 里则天然共享。

第三类是复杂派生关系。多维度汇总、漏斗计算、筛选后的合计值，这些本质上都是“根据一堆原始状态计算出来的结果”。用 createMemo 表达派生关系，既直观又高效。

6.2 不该碰 rea 的两个信号

第一，状态极其有限的时候不要硬上。如果你只需要维护三两个布尔开关，useState远比引入任何响应式系统都合适。状态量少时，手动同步的开销远低于维护依赖图的开销。

第二，已经有了成熟状态方案且运行稳定时，不要为了“响应式”而重构。Redux、Zustand 这一类方案早已解决了大部分问题，把它们替换成 rea 并不能带来质变。我见过某些团队为了用新东西而强行引入新库，最后只得到了一套没人理解的代码。

6.3 你可以在自己的项目里快速复用这套方案

如果你看完了这篇文章，想在一个小型项目里开始尝试，建议直接从上面的迷你实现入手。结合我们的经验，可以做这几件事：

• 把createSignal、createEffect、调度器先放到一个模块里，满足 80% 的联动需求；
• 给所有 effect 加一个name选项，便于开发模式下追踪触发链；
• 写一条代码规范：组件内禁止解构 createStore 返回的响应式对象；
• 所有异步依赖读取必须放在 effect 的同步执行段，这是最容易出 bug 的地方。

我自己在实际项目中的体会是：rea 这类 Signal 数据层的价值不在于帮你省掉架构设计，而在于把“数据何时变化、谁在依赖它、变化由谁触发”这些问题变得可观测、可追踪。状态管理和中间态问题依然是系统设计的一部分，只是排查起来远没有以前那么痛苦。

如果你现在正被一堆事件总线、全局变量和跨组件同步问题搞得焦头烂额，不妨抽出半天时间，自己动手实现一个极简 Signal 内核，再迁移一个小页面试试。它不会替你解决所有业务复杂度，但至少能让代码里的数据流重新变得清晰可见。