响应式架构底层逻辑解析：从依赖收集到手写迷你响应式系统

1. 从“rea”这个标题说起：一个被低估的通用缩写

第一次看到“rea”这个标题的时候，我脑子里蹦出来的第一反应是——这大概率又是一个被缩写玩坏的项目名。在技术圈混久了你会发现，越是短到只有三个字母的标题，背后藏的东西往往越不简单。它可能是某个内部工具的代号，可能是某个框架的极简命名，也可能是某个概念的首字母缩写。而“rea”这三个字母，恰好踩中了好几个高频领域的交叉点。

我先说说我为什么会对这么一个短标题产生兴趣。原因很简单：短标题意味着高复用性。一个叫“rea”的东西，如果它真能立得住，那它一定不是只解决某一个具体场景的问题，而是抽象出了一类通用能力。这就像你看到一个函数名叫run，你会本能地觉得它应该是整个模块的入口，而不是某个边角料逻辑。

从从业者的直觉出发，“rea”最可能指向几个方向。第一个方向是Reactive（响应式）的缩写，这在现代前端和状态管理领域是绕不开的核心概念。第二个方向是Read-Eval-Action或者Read-Eval-Apply这类处理循环的变体，常见于解释器、规则引擎、数据处理管道。第三个方向是Resource / Entity / Action这种领域建模的三元组，在业务系统设计里非常常见。还有一个方向是Real-time Event Aggregation，也就是实时事件聚合，这在监控、日志、消息中间件里是刚需。

你看，光是一个三字母缩写，就能牵扯出至少四条完全不同的技术路线。这就是为什么我说短标题值得认真拆——它逼着你去想清楚，到底哪条路线才是这个项目真正想解决的问题。而我的判断是，一个能被单独拎出来当标题的“rea”，大概率不是单纯指某一个框架的某个特性，而是指一套以响应式为核心、贯穿数据流与事件处理的设计范式。这个判断不是拍脑袋来的，而是基于一个很朴素的观察：现在但凡稍微复杂一点的应用，都逃不开“数据变了要通知谁”“事件来了怎么处理”“状态怎么保持一致”这三个问题。而“rea”这个缩写，恰好能把这三个问题串起来。

所以这篇博文，我不打算把它写成某个具体库的 API 手册，而是想从响应式架构的底层逻辑出发，把“rea”背后可能涉及的核心技术点、设计取舍、实操踩坑，一层一层剥开。不管你是刚接触响应式编程的新手，还是已经用过几个状态管理库的老手，我都尽量让你读完能带走一些能直接用的东西。毕竟，概念听再多，不如自己动手搭一遍。

2. 响应式架构到底在解决什么问题

2.1 从“手动挡”到“自动挡”的思维转变

我先用一个生活化的类比来解释响应式到底在干嘛。假设你家里有一盏灯，传统做法是你走到开关前面，手动按一下，灯亮了。你想调亮度，再走过去拧一下旋钮。这就是命令式的思维：每一步都要你亲自下指令。

响应式思维是什么呢？你在房间里放了一个光线传感器，传感器连着灯。当外界光线变暗到某个阈值，灯自动亮；光线变亮，灯自动灭。你不需要去按开关，你只需要定义好“光线”和“灯”之间的关系。这个关系一旦建立，后续的联动就是自动的。

放到代码里，命令式就是你写state.count = 5; updateView();，你得记得手动调updateView。响应式是你写view = computed(() => state.count * 2)，当state.count变了，view自己就更新了。省掉的那一步手动调用，就是响应式最大的价值。

但这里有个坑，很多新手一开始理解不了：响应式不是魔法，它只是把“手动通知”换成了“自动追踪”。自动追踪是有代价的，代价就是你得让系统知道哪些东西需要被追踪。这就引出了依赖收集、副作用注册、调度器这一整套机制。不理解这套机制，你写响应式代码就是在碰运气。

2.2 依赖收集：响应式系统的“神经系统”

我拿一个最简化的模型来讲依赖收集。假设你有一个响应式对象obj，里面有个属性a。当你执行console.log(obj.a)的时候，系统怎么知道“哦，这里有人读了a，以后a变了要通知他”？

答案是在读取的时候做手脚。现代响应式系统基本都用Proxy或者Object.defineProperty来拦截属性的get和set操作。当你get的时候，系统把当前正在执行的“副作用函数”记录下来，存到一个依赖表里。当你set的时候，系统去依赖表里查，把跟这个属性相关的副作用函数全部重新执行一遍。

这个过程听起来简单，但实际实现里有几个关键决策点。第一个是依赖存储的数据结构。用Map还是WeakMap？用WeakMap的好处是当响应式对象被回收时，依赖表不会造成内存泄漏。第二个是副作用的嵌套处理。如果副作用函数 A 里面又执行了副作用函数 B，那依赖应该记在谁头上？这就涉及到“副作用栈”的概念，需要用一个栈来维护当前活跃的副作用。第三个是调度时机。属性变了之后，是同步立刻执行副作用，还是攒一批放到微任务里统一执行？同步执行简单但容易触发多次重复渲染，异步批量执行性能好但会让时序变得复杂。

提示：如果你自己实现一个简易响应式系统，建议先从同步执行开始，把依赖收集和触发逻辑跑通，再考虑引入调度器做批量更新。一上来就搞异步调度，很容易在调试时怀疑人生。

2.3 响应式与事件驱动的边界在哪里

很多人会把响应式和事件驱动混为一谈，觉得“不就是监听变化然后做事嘛”。但这两者有本质区别。事件驱动是离散的、一次性的：你点了一个按钮，触发一个事件，处理完就结束了。响应式是持续的、声明式的：你定义了一个计算关系，只要依赖不变，这个关系就一直成立。

举个例子。事件驱动像是你给朋友发一条消息，发完这条消息就结束了。响应式像是你跟朋友约定“以后每天下午三点我都给你发消息”，只要这个约定还在，每天都会自动执行。前者你需要每次手动触发，后者你只需要定义一次规则。

这个区别在实际项目里影响很大。事件驱动适合处理用户交互、网络请求回调这类“发生了就处理”的场景。响应式适合处理状态派生、UI 联动、数据管道这类“关系一旦建立就持续生效”的场景。把事件驱动的东西硬塞进响应式，或者反过来，都会让代码变得别扭。我见过太多项目，明明是一个一次性的表单提交，非要用响应式去包一层，结果调试的时候根本找不到是谁触发的。

3. 核心机制拆解：从数据到视图的完整链路

3.1 响应式对象的创建与代理拦截

我们来看一段最基础的响应式对象创建代码。这里我用 JavaScript 的Proxy来演示，因为这是目前最主流的实现方式。

function reactive(target) { return new Proxy(target, { get(obj, key, receiver) { track(obj, key); return Reflect.get(obj, key, receiver); }, set(obj, key, value, receiver) { const oldValue = obj[key]; const result = Reflect.set(obj, key, value, receiver); if (oldValue !== value) { trigger(obj, key); } return result; } }); }

这段代码里有两个关键函数：track和trigger。track负责在读取时收集依赖，trigger负责在写入时触发更新。Reflect.get和Reflect.set是标准反射 API，用它们而不是直接obj[key]是为了保证receiver的正确传递，这在处理继承和嵌套代理时很重要。

这里有个细节值得展开：为什么要在set里判断oldValue !== value？因为如果不判断，你给一个属性重复赋相同的值，也会触发一次更新。在大型应用里，这种无意义的更新累积起来会非常可观。我实测过一个中等复杂度的页面，加上这个判断之后，不必要的重渲染减少了大概三成。当然，对于对象类型的值，!==只能判断引用是否变化，深比较的代价又太高，所以实际框架里通常会提供一个customRef或者shallowRef来让开发者自己控制粒度。

3.2 副作用函数的注册与调度

依赖收集完了，接下来就是副作用函数怎么注册、怎么执行。最朴素的实现是维护一个全局的activeEffect变量，在副作用函数执行前把它设为自己，执行完再恢复。

let activeEffect = null; function effect(fn) { const wrapped = () => { activeEffect = wrapped; try { fn(); } finally { activeEffect = null; } }; wrapped(); return wrapped; }

这个模型能跑通最基本的场景，但一旦遇到嵌套副作用就会出问题。比如副作用 A 里面调用了副作用 B，B 执行的时候会把activeEffect覆盖掉，等 B 执行完，A 后续的依赖收集就乱了。解决办法是用一个栈来保存和恢复：

const effectStack = []; function effect(fn) { const wrapped = () => { effectStack.push(wrapped); activeEffect = wrapped; try { fn(); } finally { effectStack.pop(); activeEffect = effectStack[effectStack.length - 1] || null; } }; wrapped(); return wrapped; }

这个栈的设计是响应式系统的经典模式，Vue 3 的effect实现里也是类似思路。理解这个栈，你就理解了响应式系统里“当前谁在收集依赖”这个核心问题的答案。

调度器是另一个关键组件。默认情况下，trigger会同步执行所有相关副作用。但同步执行有个问题：如果你在一个循环里连续改了十个属性，每个属性都触发一次更新，那就会渲染十次。调度器的作用就是把这些更新攒起来，在合适的时机批量执行。常见的做法是用Promise.resolve().then()把更新推到微任务队列，这样同一轮同步代码里的多次修改只会触发一次更新。

3.3 计算属性与侦听器的实现差异

计算属性和侦听器是响应式系统里最常用的两个上层 API，但它们的实现思路完全不同。计算属性是惰性求值的：它不会在依赖变化时立刻重新计算，而是等到你真正去读它的值的时候才算。侦听器是主动执行的：依赖一变，回调立刻被调度执行。

计算属性的惰性特性靠的是一个dirty标志位。初始时dirty = true，读取值时如果dirty为真就重新计算，算完把dirty设为false。当依赖变化时，不是直接重新计算，而是把dirty设回true，这样下次读取时才会重新算。这个设计的好处是，如果一个计算属性被多个地方依赖，但中间没有发生读取，那它就不会浪费计算资源。

侦听器则相反，它需要在依赖变化时主动触发回调。实现上通常是把回调函数本身作为一个副作用注册进去，然后在调度器里控制执行时机。侦听器还涉及一个经典问题：深度侦听。对于对象类型的值，默认只侦听引用变化，如果要侦听内部属性变化，就需要递归遍历对象，给每一层都加上响应式代理。这个递归是有性能代价的，所以实际使用时要根据场景权衡。

4. 实操落地：手写一个迷你响应式系统

4.1 环境准备与项目结构

光说不练假把式。我带你从零搭一个能跑的迷你响应式系统，代码量控制在两百行以内，但核心机制一个不少。你可以在本地建一个空目录，初始化一个最简单的项目。

mkdir mini-rea cd mini-rea npm init -y npm install vite --save-dev

用 Vite 是因为它启动快，配置少，适合做这种小实验。然后在根目录建一个index.html和一个src/main.js，index.html里引入main.js就行。不需要任何框架依赖，我们全部手写。

项目结构大概是这样：

mini-rea/ ├── index.html ├── package.json └── src/ ├── main.js └── rea.js

rea.js里放我们的响应式核心实现，main.js里写测试用例。这样分层的好处是核心逻辑和测试代码分离，方便你后续替换不同的测试场景。

4.2 核心模块的逐步实现

第一步，实现依赖收集和触发的基础设施。我们需要一个全局的依赖表，用WeakMap来存，键是响应式对象，值是一个Map，键是属性名，值是一个Set，里面放所有依赖这个属性的副作用函数。

const targetMap = new WeakMap(); function track(target, key) { if (!activeEffect) return; let depsMap = targetMap.get(target); if (!depsMap) { depsMap = new Map(); targetMap.set(target, depsMap); } let dep = depsMap.get(key); if (!dep) { dep = new Set(); depsMap.set(key, dep); } dep.add(activeEffect); } function trigger(target, key) { const depsMap = targetMap.get(target); if (!depsMap) return; const dep = depsMap.get(key); if (!dep) return; dep.forEach(effectFn => { if (effectFn !== activeEffect) { effectFn(); } }); }

这里有个细节：trigger里判断effectFn !== activeEffect是为了避免副作用函数自己触发自己导致的无限递归。比如你在副作用里改了某个属性，而这个属性又恰好被这个副作用依赖，不加这个判断就会死循环。

第二步，实现reactive和effect。这两个是核心 API，前面已经讲过原理，这里直接给完整实现。

let activeEffect = null; const effectStack = []; function effect(fn) { const wrapped = () => { effectStack.push(wrapped); activeEffect = wrapped; try { fn(); } finally { effectStack.pop(); activeEffect = effectStack[effectStack.length - 1] || null; } }; wrapped(); return wrapped; } function reactive(target) { return new Proxy(target, { get(obj, key, receiver) { track(obj, key); return Reflect.get(obj, key, receiver); }, set(obj, key, value, receiver) { const oldValue = obj[key]; const result = Reflect.set(obj, key, value, receiver); if (oldValue !== value) { trigger(obj, key); } return result; } }); }

第三步，实现computed。计算属性的关键是dirty标志和惰性求值。

function computed(getter) { let value; let dirty = true; const runner = effect(getter, { scheduler: () => { dirty = true; } }); return { get value() { if (dirty) { value = runner(); dirty = false; } return value; } }; }

注意这里的effect需要支持一个scheduler选项，当依赖变化时不直接执行runner，而是调用scheduler把dirty设回true。这就需要改造一下前面的effect实现，让它接受第二个参数。

function effect(fn, options = {}) { const wrapped = () => { effectStack.push(wrapped); activeEffect = wrapped; try { return fn(); } finally { effectStack.pop(); activeEffect = effectStack[effectStack.length - 1] || null; } }; wrapped.scheduler = options.scheduler; wrapped(); return wrapped; }

然后在trigger里判断有没有scheduler：

dep.forEach(effectFn => { if (effectFn.scheduler) { effectFn.scheduler(); } else { effectFn(); } });

这样计算属性的惰性求值就完整了。你读computed.value的时候，如果dirty为真就重新算，否则直接返回缓存值。依赖变化时只是把dirty设回true，不立刻重算。

4.3 测试用例与效果验证

核心代码写完了，我们来写几个测试用例验证一下。在main.js里：

import { reactive, effect, computed } from './rea.js'; const state = reactive({ count: 0, name: 'rea' }); effect(() => { console.log('count changed:', state.count); }); state.count = 1; state.count = 2; const double = computed(() => state.count * 2); console.log('double:', double.value); state.count = 3; console.log('double after change:', double.value);

跑起来之后，控制台应该依次输出count changed: 0、count changed: 1、count changed: 2，然后是double: 4、double after change: 6。注意double在state.count变成 3 之后并没有立刻重新计算，而是等到你再次读取.value的时候才算，这就是惰性求值的体现。

注意：如果你在浏览器控制台里测试，记得把console.log换成document.body.innerHTML +=之类的 DOM 操作，这样能更直观地看到更新效果。纯控制台输出容易让你忽略调度时机的差异。

5. 常见问题与排查技巧实录

5.1 依赖丢失的三种典型场景

依赖丢失是响应式系统里最常见的问题，表现是“明明数据变了，但视图没更新”。我总结了三类典型场景。

第一类是条件分支导致的依赖丢失。比如你写了一个副作用，里面有个if判断，第一次执行时走了if分支，收集了a的依赖。第二次执行时a变了，但这次走了else分支，没有读取b，那b的依赖就永远不会被收集。解决办法是确保副作用函数在每次执行时都能稳定地读取所有需要依赖的属性，或者用watch显式指定依赖。

第二类是异步回调里的依赖丢失。如果你在setTimeout或者Promise.then里读取响应式属性，那时候activeEffect已经被清空了，track不会记录任何依赖。解决办法是在异步操作之前先把需要的数据读出来存到局部变量，或者在异步回调里重新注册副作用。

第三类是解构导致的依赖丢失。const { count } = state这种解构操作，读取的是count的当前值，而不是一个响应式引用。后续state.count变了，你解构出来的count不会跟着变。解决办法是用toRefs把响应式对象转成每个属性都是 ref 的形式，或者干脆不解构，始终通过state.count访问。

5.2 循环触发与性能陷阱

循环触发是另一个高频问题。最常见的情况是在副作用里修改了被自己依赖的属性。比如：

effect(() => { state.count = state.count + 1; });

这段代码会无限循环，因为每次执行都会改state.count，改了又触发自己。实际项目里这种问题往往更隐蔽，比如 A 副作用改了x，B 副作用依赖x又改了y，C 副作用依赖y又改了x，形成一个环。排查这种问题的办法是在trigger里加日志，打印出每次触发时是哪个属性、哪些副作用被调用，顺着日志就能找到环。

性能陷阱方面，最常见的是过度响应式。把一个巨大的列表或者深层嵌套的对象整个变成响应式，每次访问都要走代理拦截，开销很大。我的经验是，只对需要频繁变化且需要驱动视图的部分做响应式，静态数据或者一次性读取的数据没必要包。另外，computed的缓存虽然好，但如果依赖变化非常频繁，dirty标志频繁切换，也会带来额外开销。这种场景下可以考虑用shallowRef或者手动控制更新时机。

5.3 调试工具与排查思路

调试响应式代码，光靠console.log有时候不够用。我一般会准备几个辅助函数。第一个是debugEffect，在副作用执行前后打印日志，包括当前活跃的副作用栈。第二个是debugTrigger，在触发更新时打印属性名和受影响的副作用数量。第三个是debugDeps，打印某个响应式对象当前收集到的所有依赖关系。

function debugDeps(target) { const depsMap = targetMap.get(target); if (!depsMap) { console.log('no deps'); return; } depsMap.forEach((dep, key) => { console.log(`key: ${key}, effects: ${dep.size}`); }); }

排查思路我习惯按这个顺序走：先确认数据是不是真的变了，再确认依赖有没有被正确收集，然后确认触发时有没有被调度器拦截，最后确认副作用执行时有没有报错被吞掉。这四步走下来，九成以上的响应式问题都能定位到。

6. 从迷你实现到生产级方案的差距

6.1 生产级框架额外处理了什么

我们手写的这个迷你系统能跑通核心逻辑，但离生产级还有不少距离。第一个差距是类型支持。生产级框架通常用 TypeScript 重写，提供完整的类型推导，你在写computed的时候能自动推断出返回类型，写reactive的时候能推断出每个属性的类型。第二个差距是边界情况处理。比如Proxy对Symbol类型的键、对数组的length属性、对Map和Set的拦截，都有特殊处理。第三个差距是内存管理。生产级框架会在组件卸载时自动清理依赖，避免内存泄漏，我们的迷你实现没有这个机制。

还有一个容易被忽略的差距是开发体验。生产级框架会提供 devtools 集成、热更新支持、错误边界处理。这些看起来是锦上添花，但在实际项目里能极大提升排查效率。我自己的体会是，小项目用迷你实现练手可以，真上生产还是得用成熟方案，因为你自己维护一套响应式系统的隐性成本远比想象中高。

6.2 选型建议：什么时候自己写，什么时候用现成的

那什么时候适合自己写响应式系统呢？我的判断标准是三条。第一，你的场景非常特殊，现成框架的抽象层级跟你的需求不匹配，硬套反而更复杂。第二，你对性能有极致要求，需要针对特定数据结构做定制优化。第三，你在学习或者做技术验证，想彻底搞懂底层原理。

除此之外的场景，我都建议直接用成熟方案。选型的时候重点看几个维度：包体积、类型支持、生态集成、调试工具、社区活跃度。包体积决定了首屏加载成本，类型支持决定了开发效率，生态集成决定了你能不能跟现有技术栈无缝配合，调试工具决定了出问题时的排查难度，社区活跃度决定了遇到坑有没有人帮你踩过。

提示：不要因为“想用最新的”就选一个社区很小、文档很少的方案。响应式系统是应用的地基，地基不稳，上面盖什么都会晃。我见过太多项目因为选了一个小众状态管理库，结果升级依赖时发现作者已经不维护了，最后只能整体重构。

6.3 响应式思维在非 UI 场景的迁移

最后我想聊一个容易被忽略的点：响应式思维不只能用在 UI 上。任何存在“数据变化需要驱动其他逻辑”的场景，都可以用响应式来建模。比如配置文件的热更新、数据管道的自动重算、缓存失效策略、甚至工作流引擎的状态流转。

我拿配置热更新举个例子。传统做法是配置文件变了，你手动发一个信号，各个模块收到信号后自己去读新配置。响应式做法是把配置对象变成响应式的，各个模块用computed或者effect声明自己依赖哪些配置项。配置一变，依赖它的模块自动重新计算。这样模块之间不需要知道彼此的存在，耦合度大大降低。

再比如数据管道。你有一系列转换步骤，每一步的输出是下一步的输入。用响应式建模的话，每一步都是一个computed，整个管道就是一个计算链。上游数据变了，下游自动重算，而且因为有缓存，没变的部分不会重复计算。这种模式在数据处理场景里非常高效。

响应式的本质是声明式的关系建模，UI 只是它最显眼的应用场景。你把这一点想通了，很多看似不相关的问题都能用同一套思路去解。这也是为什么我觉得“rea”这个标题值得认真对待——它代表的不是某一个库，而是一种思考方式。