从零实现轻量级响应式系统：依赖收集与触发更新全解析

拿到这个标题的时候，我盯着"rea"三个字母看了好一会儿。项目标题就这么多，没有技术栈说明，没有背景文档，也没有需求清单。干这行久了，对这种三字母代号其实并不陌生，内部项目里经常出现这种被截断的内部代号，它往往不是凭空捏造的名字，而是某个核心能力被拧掉一半剩下的骨架。我把"rea"读成 reactive——响应式。这是声明式前端最核心、也最值得亲手实现一遍的东西。

这篇文章就是一次完整的"rea"项目复盘：从一个只有代号、没有需求的最小起点出发，从零实现一个轻量级响应式系统，讲清楚依赖收集、触发更新、computed 惰性求值这些核心机制，再看它怎么结合 DOM，跑成一个能交互的真实 Demo。想弄明白主流声明式框架底层到底在做什么的同学，或者打算在内部工具链里自研轻量绑定层的老手，都可以拿这套东西当参考。代码全部是标准 JavaScript，不需要任何构建工具，复制下来就能跑。

1. 项目定位：从三个字母到一份明确需求

1.1 三个字母的不同解码方式

行业里项目代号并不总是完整单词。常见的习惯是取核心模块的动词前缀，"rea"可能是 reactive、read、real-time 之类词汇的截断。技术背景不同的同事看到同一个代号，理解往往完全不一样：会计领域的同事可能想到资源-事件-参与者模型，音视频方向的同事可能想到某个音频引擎，前端同学大概率会往响应式上靠。

在没有更多上下文的情况下，最合理的做法是选一个对团队实际业务帮助最大的方向。响应式系统正是在当前前端业务中影响面最大的底层能力之一，把它吃透，以后排查状态类问题会省下大量时间。所以这个项目的目标定为：实现一个极简但完整的响应式系统，代号就叫"rea"。

1.2 设计目标与取舍清单

动手之前先把边界划清楚。我不打算把 rea 做成一个要跟主流框架正面竞争的东西，而是做成一个核心原理完整、代码足够短、能塞进静态页面的迷你响应式层。项目的设计目标有这么几条：

• 不引入任何第三方依赖，纯标准 JavaScript 实现
• 核心 API 只有 reactive、effect、computed 三件套
• 能通过简单的 DOM 指令完成数据和视图的绑定
• 代码总量控制在 150 行以内，适合逐行阅读

做这类项目最容易犯的错是一上来就想做模板编译器、虚拟 DOM、组件生命周期。那些东西当然有价值，但会把核心逻辑淹没在大量外围代码里。先把数据劫持、依赖收集、触发更新这条主链路打通，比什么都重要。

下表和当前主流的声明式框架做个粗略对比，方便看出定位差异：

能力维度	传统手写 DOM	rea	主流声明式框架
数据变化更新视图	手动操作	自动	自动
依赖追踪粒度	无	属性级	属性级或组件级
模板编译	无	简易指令	完整编译器
周边生态	无	无	丰富
学习成本	低	适中	偏高
代码量	看手气	极小	较大

这笔账算下来，rea 的适用场景很明确：静态页面、内部工具、教学项目，以及不想为一个小功能引入庞大依赖的场景。它的核心价值不在替代谁，而是用最直白的方式把"数据驱动视图"这件事讲明白。

2. 响应式系统的核心机制，终于被拆开了

2.1 依赖收集：从电子表格说起的模型

理解响应式系统最简单的方式，是回想一下电子表格里的单元格公式。A1 单元格里写了一个公式A2 * A3，当你修改 A2 的值时，A1 会自动计算出新结果。电子表格软件内部做的事情是：记录"哪个单元格依赖谁"以及"谁被依赖了"。

前端响应式系统一模一样。数据对象相当于单元格，读取数据的地方相当于公式。当一个函数读取了某个响应式字段，系统要记住"这个函数依赖那个字段"。之后字段一变，就去通知所有依赖它的函数重新执行。这套机制有一个专门的名字：依赖收集。

依赖收集在代码层面分成两半，一半叫 track，负责在读取数据时记录依赖；另一半叫 trigger，负责在数据变化时拿出依赖并逐一通知。很多入门教程把它们描述得很玄，说白了就是两个带映射关系的登记簿。

2.2 用 Proxy 完成 get 收集、set 通知

实现响应式系统要解决一个基本问题：我怎么知道代码在读取某个字段，又该怎么知道字段被修改了？早年主流做法是用 defineProperty 逐个属性改写 getter 和 setter，需要提前遍历对象所有属性，属性新增还要额外处理。现在标准 JavaScript 里的 Proxy 可以直接代理整个对象，读写操作都能被拦截，代码简洁很多。

我在这里直接给出 rea 的数据劫持部分。核心结构是三层映射：WeakMap 记录对象，Map 记录对象的每个键，Set 记录依赖该键的所有副作用函数。选 WeakMap 而不是普通 Map 的原因在于弱引用，当原对象不再被使用的时候，WeakMap 里的记录可以被垃圾回收，不会拖累内存。

let activeEffect = null; const effectStack = []; 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); activeEffect.deps.push(dep); } function trigger(target, key) { const depsMap = targetMap.get(target); if (!depsMap) return; const deps = new Set(); const dep = depsMap.get(key); if (dep) { dep.forEach(eff => { if (eff !== activeEffect) deps.add(eff); }); } deps.forEach(eff => { if (eff.options.scheduler) { eff.options.scheduler(eff); } else { eff(); } }); } function reactive(obj) { return new Proxy(obj, { get(target, key, receiver) { const res = Reflect.get(target, key, receiver); if (typeof key !== 'symbol') { track(target, key); } return res; }, set(target, key, value, receiver) { const oldValue = target[key]; const result = Reflect.set(target, key, value, receiver); if (oldValue !== value && typeof key !== 'symbol') { trigger(target, key); } return result; }, deleteProperty(target, key) { const hadKey = key in target; const result = Reflect.deleteProperty(target, key); if (hadKey && typeof key !== 'symbol') { trigger(target, key); } return result; } }); }

每个副作用的 dep 都是一组 Set，两个作用：第一，同一个副作用重复读取同一字段时不会重复登记；第二，后面做依赖清理时删除操作是常数时间。

2.3 effect 执行单元与依赖清理

有了 reactive，还需要一个"执行单元"让副作用函数跑起来并完成依赖收集。这个执行单元就是 effect。它是响应式系统里最核心的概念之一：一个普通函数被包进 effect 后，首次执行时内部所有响应式字段的读取都会完成 track，后续这些字段变化都会触发它重新执行。

这里有个看似简单但容易埋坑的问题：effect 如果重新执行，旧的依赖集合会残留吗？比如一个函数里用 if 分支，第一次走 A 分支读取了字段 a，第二次走 B 分支没有读 a。如果不清除旧依赖，a 仍然保留着对它的引用，以后 a 一变这个 effect 依然会被触发，做很多无意义的重跑。所以每个 effect 重新执行前都要先做一次 cleanup，把上一次登记的依赖全部摘干净，然后重新收集。

function cleanup(effectFn) { for (let i = 0; i < effectFn.deps.length; i++) { const dep = effectFn.deps[i]; dep.delete(effectFn); } effectFn.deps.length = 0; } function effect(fn, options = {}) { const effectFn = () => { cleanup(effectFn); effectStack.push(effectFn); activeEffect = effectFn; try { return fn(); } finally { effectStack.pop(); activeEffect = effectStack[effectStack.length - 1]; } }; effectFn.options = options; effectFn.deps = []; if (!options.lazy) { effectFn(); } return effectFn; }

effectStack 是为了处理嵌套 effect 而存在。当外层 effect 执行到一半又新建了一个内层 effect，内层执行结束后 activeEffect 要恢复成外层 effect。没有这个栈，后面的 track 会把依赖记到错误的对象上。这是新手实现响应式时最容易忽略的细节。

3. 实操闭环：跑起来一个能够交互的最小应用

3.1 目录结构与初始化

项目不需要构建工具，三个文件就能跑。按我平时做教学 Demo 的习惯，目录结构是这样：

rea-demo/ ├── index.html ├── rea.js └── main.js

index.html 里放视图结构，rea.js 放响应式核心，main.js 放业务绑定。直接双击打开 index.html 就能看到效果，也可以起一个任意静态服务方便调试。这个零依赖的设定很重要，它让排查问题的变量少了很多：页面不正常，要么是我写的核心逻辑有问题，要么是业务代码有问题。

3.2 核心代码：reactive、effect、computed 一起落地

rea.js 里先放入前面实现的 reactive、track、trigger、cleanup、effect。在此基础上我加一个 computed，它负责"根据多个响应式数据计算出一个派生值"，并且只在真正需要的时候求值。

computed 的实现要点是脏标记。它内部有一个 effect 以 lazy 模式运行，真正读取 value 时才执行求值函数并收集依赖。被依赖的数据发生变化时，不立即重新求值，而是把脏标记置为 true，同时触发所有读取过这个 computed 值的外层 effect 重新运行。这样既避免了重复计算，又能保证数据变化最终反映到视图上。

function computed(getter) { let dirty = true; let value; const effectFn = effect(getter, { lazy: true, scheduler() { if (!dirty) { dirty = true; trigger(obj, 'value'); } } }); const obj = { get value() { if (dirty) { value = effectFn(); dirty = false; } track(obj, 'value'); return value; } }; return obj; }

export 部分按模块语法导出，注意这里没有给 rea 起任何包名，保持一个内部工具应有的朴素感。

3.3 视图绑定与事件绑定

响应式核心做好后，还要让它跟 DOM 建立起联系。我采用最朴素的做法：给 HTML 元素加上两个自定义属性。data-text 表示这个元素的文本内容由某个表达式驱动，data-model 表示某个输入框的值负责回写响应式字段。

绑定函数 bindText 把一个 effect 和元素文本节点绑定，bindModel 处理输入框。这里最直观地展示了 effect 的威力：原本需要手动监听事件再赋值给 DOM 的流程，现在只要声明"这个元素的文本等于某个值"，后面什么都不用管了。

function bindText(el, getValue) { effect(() => { el.textContent = getValue(); }, { scheduler: job => queueJob(job) }); } function bindModel(el, key) { effect(() => { el.value = state[key]; }, { scheduler: job => queueJob(job) }); el.addEventListener('input', () => { state[key] = parseFloat(el.value) || 0; }); }

bindModel 里那只监听 input 的回调是在事件阶段触发，此时 activeEffect 已经不存在，所以它只是修改数据，不会污染依赖收集过程，这是正确的行为。注意事件回调里读取或写入 state 的时机，这一步出问题会导致响应式丢失，后面第三节会详细排查。

3.4 Demo：单价与数量联动总价

我在 index.html 里放一个最经典的场景：两个输入框分别代表单价和数量，一个文本节点显示总价，总价由 computed 派生。HTML 结构如下：

<input type="number">import { reactive, computed, effect } from './rea.js'; const state = reactive({ price: 12, count: 5 }); const total = computed(() => state.price * state.count); document.querySelectorAll('[data-model]').forEach(el => { bindModel(el, el.getAttribute('data-model')); }); const totalEl = document.querySelector('[data-text="total"]'); bindText(totalEl, () => total.value); const priceEl = document.querySelector('[data-text="price"]'); bindText(priceEl, () => state.price);

打开页面后，修改单价输入框，总价和单价文本会同时更新。修改数量，总价更新。整个过程没有任何手动 DOM 操作，全部由依赖链驱动：数据 → computed → 视图 effect。

一个值得注意的细节是总价显示 effect 本身并不直接订阅 price 和 count，它只订阅了 total.value。但因为 total.value 的 getter 内部会 track price 和 count 到 computed 的 effect，数据变化时会先通知 computed 把脏标记置为 true，再通知视图 effect 重新读取 total.value，从而拿到新值。这是一个完整的依赖链，也是理解响应式数据流的关键。

3.5 调度器：把多次更新合并为一次

目前实现的 trigger 遇到数据变化会同步执行所有 effect。连续修改两个字段会产生两次视图更新，这在真实项目里既浪费性能，也可能让中间状态被渲染出来造成闪烁。主流的响应式框架都会引入调度器，统一管理 effect 的执行时机。

rea 增加一个极简调度器，利用 Promise 的微任务把同一次事件循环里的多个更新请求合并成一次：

const jobQueue = new Set(); let isFlushing = false; const promise = Promise.resolve(true); function queueJob(job) { jobQueue.add(job); if (!isFlushing) { isFlushing = true; promise.then(() => { try { jobQueue.forEach(fn => fn()); } finally { isFlushing = false; jobQueue.clear(); } }); } }

bindText 和 bindModel 里传给 effect 的 scheduler 都改成 queueJob，这样数据更新后视图刷新会推迟到当前同步代码执行完。效果上等于做了自动的批量更新：即使在一次事件处理里改五遍 price，最终视图只会刷新一次，而且刷到的永远是最后一个值。

4. 生命周期与进阶细节：除了能跑，还要正确

4.1 computed 的脏标记与缓存策略

computed 有两个容易被忽略的优化点：懒执行和缓存。懒执行指 computed 的求值函数在创建时不会跑，只有第一次读取 value 才执行。缓存指在依赖没有变化的情况下，多次读取 value 不会重复执行求值函数，直接返回上一次的结果。

脏标记的切换流程可以整理成一张表：

场景	dirty 初始值	行为
首次读取 value	true	执行求值函数，dirty 置为 false
再次读取 value	false	直接返回缓存，不再计算
依赖字段变化	由 scheduler 置为 true	不立即重算
变化后首次读取 value	true	重新执行求值函数

这个设计适合读多写少的派生数据，比如商品列表的过滤结果、购物车总价、用户权限信息。在大量组件同时读取同一个 computed 值时，缓存价值尤其明显。

4.2 嵌套 effect：父子依赖与执行顺序

实际业务里 effect 之间经常存在嵌套关系。典型场景是一个组件级 effect 渲染多个子节点，子节点内部又有自己的 effect。嵌套执行时 effectStack 保证了依赖归属正确。

假设有一个外层效果先读取了父级字段，然后内部创建内层效果读取子级字段，子级字段变化时只触发内层效果，父级字段变化时触发外层效果重建整个块。这种树形结构是视图组件层级很自然的映射。如果不在嵌套场景里恢复 activeEffect，内层执行完成后，外层后续的读取会被错误地注册到内层 effect 上，导致数据关联错乱。

4.3 停止跟踪：什么时候需要主动解绑

响应式系统默认的行为是只要依赖存在，effect 就会一直跟踪、持续更新。但在一些场景里这是多余的，比如一个弹窗组件已经关闭，它对应的 effect 还在监听全局状态变化并操作已销毁的 DOM。这时需要主动停止跟踪。

实现 stop 只需要把 effectFn 从所有 dep 集合中移除，并且在下一次调用时阻止它继续 track。在 rea 中可以这样处理：

function stop(effectFn) { cleanup(effectFn); effectFn.active = false; // 在 effectFn 执行前判断，若 active 为 false 直接 return }

注意 stop 后旧依赖已经清除，新读取也会被拦住，所以被 stop 的 effect 不会再因为任何字段变化而执行。这个能力在做窗口销毁、组件卸载、事件解绑时非常有用，能避免大量无意义的计算和内存占用。

5. 项目实战中的问题与排查技巧

5.1 页面不更新的高频原因汇总

把 rea 落到实际页面里之后，会碰到一些很典型的"数据明明变了、页面却不刷新"的现象。我在下面表格里整理了最常踩的五个坑，全部是实操中确认过的场景：

现象	可能原因	排查方向
数据变了但文本没变	读取操作不在 effect 内部	查看绑定函数是否被 effect 包裹
解构后修改不生效	const { price } = state 后 price 是普通值	使用 state.price 而不是解构变量
新增属性不触发更新	该键从未被 track，没有依赖可通知	提前声明字段或在 effect 中读取该键
数组索引变化不更新	数组 length 未被 track	对数组索引额外处理 length 的 trigger
异步回调里读取没反应	回调执行时 activeEffect 已为空	把读取逻辑放回 effect 函数体内

最常见的还是解构问题。const { price } = state之所以会丢失响应式，根本原因是解构只在那一瞬间读取了一次 price，之后 price 变成一个不再经过 Proxy 的普通变量。后续对 price 的赋值其实是在给局部变量赋值，和 state 完全无关。这也是为什么响应式代码里更推荐直接写 state.price，或者封装一个 ref 风格的转换层。

5.2 死循环、丢更新与排查三板斧

响应式系统跑出死循环通常不是单 effect 自增长造成的。我们的 trigger 在通知依赖时会跳过当前正在执行的 activeEffect，所以一个 effect 内部写回同一个字段不会无限递归。真正危险的是多个 effect 形成的循环依赖：effect A 读字段 x，effect B 读字段 y，A 写 y 触发 B，B 又写 x 触发 A，二者互相唤醒直到栈溢出。

遇到这类问题，我的排查三板斧是：先把 scheduler 临时改回同步执行，方便在 trigger 里打断点；然后在 trigger 第一行打印 target 和 key，观察谁在非法触发；最后看调用栈，找到循环产生的路径。一旦定位到循环里的某一次写入，就把那行代码去掉或改为条件写入，环路自然断开。

丢更新的问题则多半跟调度器有关。用 Promise 微任务批量更新时，如果两个 effect 都依赖同一批数据，合并执行时后一个可能读到最新的值，看起来好像"中间那次更新丢了"。这其实是设计的预期行为，不是 bug。如果业务确实需要每一次赋值都同步渲染，可以为特定 effect 显式传入同步 scheduler。

5.3 排查手段：可视化依赖与调用栈

最后分享一个我从老项目里带过来的调试习惯：在开发环境给 targetMap 增加一个打印方法，把对象、键、依赖的 effect 一一列出来。这样调试时可以直观看到某个字段被哪些 effect 订阅，以及某个 effect 订阅了哪些字段。

function debugDependencies(target, key) { const depsMap = targetMap.get(target); if (!depsMap) return []; return Array.from(depsMap.get(key) || []); }

配合浏览器控制台的 console.trace，几乎可以把响应式系统内部的状态全部外显出来。这个方法比盲改代码高效得多，尤其适合排查那些"明明订阅了却不更新"的疑案。

6. 工程化落地：从 Demo 到能用

6.1 模块化与单元测试

把 rea 从单文件 Demo 变成可维护模块，第一步是拆文件。按职责分成 reactive.js、effect.js、computed.js、scheduler.js 和 bind.js，每个文件只干一件事。模块边界清晰后，单元测试也好写了。

我给 rea 写了几条最基础的测试用例，覆盖三条主干链路：effect 首次执行、依赖变化后重新执行、computed 缓存生效。用纯 Node 就能跑，不引入测试框架：

let result = 0; const state = reactive({ count: 1 }); effect(() => { result = state.count * 2; }); console.assert(result === 2); state.count = 5; console.assert(result === 10);

这种测试虽然粗糙，但在一个自研小库里已经能挡住大部分回归。等到模块再复杂一些，再换正式测试框架也不迟。

6.2 什么场景适合用这类轻量响应式层

做完 rea 之后，我反而对"什么时候别用框架"有了更清晰的判断。它适合的场景往往是这些：不需要组件化的静态营销页、老项目里局部新增的交互模块、已有构建工具但不想引入重型依赖的内部工具。

不适合的场景也很明确：团队规模大、业务状态复杂、需要长期迭代的大型应用。这类场景里，主流框架的生态、性能优化和社区问题库才是真正的护城河。rea 的定位始终是"搞清楚原理"和"解决轻量问题"，不是替代品。

6.3 可以继续做的扩展方向

如果想把 rea 继续往下推，我会优先做这几件事：给数组方法补上完整的拦截逻辑，保证 push、splice、根据索引修改等操作都能触发正确依赖；支持 ref 和 toRefs 风格 API，解决解构丢响应式的问题；提供一个 watch 函数，监听数据变化并执行异步任务。

再往上走就是模板编译器了。把>