1. 从“rea”出发：为什么我要给自己造一个响应式小轮子

“rea”这个名字是我给一个内部项目起的代号。它源于“reactive”的前三个字母，也恰好和“real”只差一个字母。我个人的理解是：真正的响应式系统，应该像真实世界里的物理反馈一样自然——你推门，门就开；你按开关，灯就亮。前端里我们天天聊响应式，从双向绑定到状态管理，从发布订阅到依赖收集，看似概念满天飞，其实核心就一句话：当数据发生变化时，所有依赖这个数据的东西自动跟着变。

这个项目的诞生背景很朴素。日常开发时我经常遇到一类尴尬：某个页面里既有表单输入、实时搜索、筛选条件，又有购物车数量联动、列表局部刷新。用现成的重型状态管理方案当然可以，但小场景里引入一整套框架，总觉得杀鸡用了牛刀。于是我想了解响应式到底能轻到什么程度——能不能用几十行代码，写一个足够自洽、足够易懂的响应式状态管理工具？这就是“rea”项目的初衷。

适合阅读这篇内容的人，我认为有三类：一类是刚接触Vue或React响应式原理，想从零理解“数据变了视图怎么跟着变”的新手；第二类是工作中经常处理表单联动、列表刷新、组件通信场景，但不想每次都被框架绑死的前端开发者；第三类纯粹是喜欢造轮子、想看看发布订阅和依赖收集到底怎么实现的爱好者。如果你是其中任意一类，这篇内容会告诉你我从设计到实现、从踩坑到补丁的全部过程，代码可以直接抄走用。

做“rea”的时候，我给自己定了三条规则：核心逻辑不超过200行、不依赖任何第三方库、注释完整到新手也能看懂。现在回看，这三条规则帮了大忙——“不超过200行”逼我砍掉冗余设计，“不依赖第三方库”逼我把事件循环和依赖收集吃透，“注释完整”逼我真正理解每一行代码为什么存在。这篇文章不仅仅是一次结果展示，更是把整个思考过程摊开给你看，所以我会把“为什么这么设计”也一并讲清楚。

2. 整体设计与思路拆解

2.1 响应式的核心矛盾：变化从哪来，更新到哪去

先从一个最基本的问题开始：响应式系统要解决的，本质上是一对矛盾——数据变更的来源是无穷无尽的，而视图更新的目标却是具体明确的。按钮点击会改数据、接口返回会改数据、定时器会改数据、用户输入会改数据，但最终需要更新的，可能只是页面上的三个数字和一个样式类名。

如果我们用最简单粗暴的“全量刷新”思路，页面任何数据变了都重新渲染整个视图，那性能和体验都会崩掉。所以我们需要的是一种机制：精确记录“谁”在“什么时候”读了“哪个数据”，然后在数据变化时，只通知这些“谁”去更新。这就是响应式系统最底层的逻辑，也是“rea”整个设计的出发点。

初次接触这个概念的人，可以类比一个现实场景：一间办公室里，只有三个人关注“今天是否下雨”——一个负责带伞的、一个负责关窗的、一个负责安排户外活动的。这时候气象台不需要广播给全楼所有人的，只需要把下雨的消息通知到这三个人就行。响应式系统的本质，就是找到这三个人并维护他们的联系方式，天气一变就精准通知。

2.2 发布订阅模式：最朴素的通信骨架

实现上述机制，最基础的设计模式是发布订阅。整个“rea”项目的骨架，就是一个事件中心：数据和视图之间通过“订阅”建立联系，数据变化时通过“发布”触发更新。我最初只写了这样一个事件中心，大概只有十来行代码：

// 极简事件中心：rea 的第一层骨架 class ReaEventBus { constructor() { this.events = new Map(); } on(name, handler) { if (!this.events.has(name)) { this.events.set(name, []); } this.events.get(name).push(handler); } off(name, handler) { if (!this.events.has(name)) return; const handlers = this.events.get(name).filter(h => h !== handler); if (handlers.length > 0) { this.events.set(name, handlers); } else { this.events.delete(name); } } emit(name, payload) { if (!this.events.has(name)) return; // 遍历时要拷贝一份，防止 handler 里再次触发 off 导致遍历异常 const handlers = this.events.get(name).slice(); handlers.forEach(handler => { try { handler(payload); } catch (err) { console.error(`ReaEventBus: 事件 ${name} 的回调执行出错`, err); } }); } }

这段代码虽然简单，但里面已经藏了一个关键技巧：emit时先slice()拷贝一份 handlers 列表。这是我在实际开发中踩过的坑——曾经有一次在某事件回调里调用了off把自己移除了，结果遍历时索引错乱，后面的事件回调全部没执行到。从那次以后，我写发布订阅必定注意“遍历快照”的问题。

2.3 为什么不能只停留在发布订阅

如果只是事件通信，那“rea”和普通的 EventEmitter 没有本质区别。普通发布订阅有一个硬伤：你需要手动维护事件名和订阅关系。比如我要让“购物车数量”这个数据变化时自动更新“总价”文本，我得手动写：

bus.on('cartChanged', updateTotalPrice); // 然后在某个地方 bus.emit('cartChanged', newCart);

这种写法的问题在于，手动维护字符串事件名的过程极易出错。事件名拼错了、订阅忘了写、发布的时候漏了某个场景，都会导致线上出现“数据改了视图却没变”的诡异问题。这种问题排查起来非常痛苦，因为报错信息往往不会直接告诉你“你忘了订阅”。

所以“rea”的第二层设计，就是把这个过程自动化：用数据对象本身来承载依赖关系，而不是用手动事件名来串。这样视图里用到哪个数据，系统就自动把更新函数记在哪个数据名下。数据一变，系统自动找到它名下所有更新函数并执行。这就是依赖收集机制，也是“rea”会比一个普通事件中心高级的地方。

2.4 最终形态的架构分层

经过反复调整，“rea”最终形成四个层次，每个层次只依赖自己的下层，互不越界：

这个分层的好处是：每一层的代码量都很少，用的时候可以根据场景只加载需要的部分。一个小页面只需要 ReaValue 就够，涉及派生数据再加一个 ReaComputed，要管理全局状态时再把 ReaStore 拉上来。这种渐进式的体积控制，在大框架里是做不到的，却是轻量方案的独有优势。

3. 核心细节解析与实操要点

3.1 ReaValue 的实现：数据怎么做到“自带感知”

ReaValue 是“rea”的最小单元。它本质上是一个持有值的对象，但这个对象用 JavaScript 的 getter/setter 拦截了对value属性和.get()/.set()方法的访问。之所以同时保留属性和方法两种访问方式，是为了兼顾代码写法的灵活性和兼容性——属性访问写起来自然，方法访问在某些框架环境中更稳定。

// ReaValue 的核心实现 function createReaValue(initialValue) { // 存放该数据依赖的订阅回调 const subscribers = new Set(); let currentValue = initialValue; // 依赖收集：谁读取了当前数据，就记录下来 function track(observer) { if (observer && !subscribers.has(observer)) { subscribers.add(observer); } } // 派发更新：数据变化时，通知所有订阅者 function trigger() { // 拷贝快照后遍历，和事件中心的道理一致 Array.from(subscribers).forEach(observer => { try { observer(currentValue); } catch (err) { console.error('ReaValue: 订阅回调执行出错', err); } }); } return { get value() { // 如果正处于某个“响应上下文”中，就自动收集它 collectDependency(track); return currentValue; }, set value(nextValue) { // 核心优化：值没变化就不触发更新 if (Object.is(currentValue, nextValue)) return; currentValue = nextValue; trigger(); }, get() { // 方法式访问 collectDependency(track); return currentValue; }, set(nextValue) { this.value = nextValue; }, subscribe(fn) { subscribers.add(fn); return () => subscribers.delete(fn); } }; }

这里最关键的细节是Object.is(currentValue, nextValue)这一行。有人可能觉得值没变化不触发是理所当然的优化，但在实际开发里，这个判断能避免大量死循环。比如某个响应式回调里又写了同名数据，如果每次 set 都触发更新，就会像“自己喊自己的名字”一样无限递归。加上这个判等逻辑之后，重复赋值被静默忽略，循环链条被直接斩断。

3.2 依赖收集是怎么实现的：全局栈与魔法一般的自动追踪

要理解依赖收集，先要理解什么是“响应上下文”。想象这样一个场景：我有一段公式代码total = price * count，当price或count变化时，total要重新计算。这个场景里，total的更新函数就是一个“响应上下文”——它正在执行的过程中，凡是读到的响应式数据，都应该把这个上下文登记为订阅者。

“rea”实现自动追踪的思路很简单，只有一个全局变量和一个栈结构。我先定义一个全局容器用来存放“当前正在执行的更新函数”，当 ReaValue 的 getter 被触发时，就读取这个全局容器，如果有函数就把它加入订阅者名单。代码如下：

// 全局依赖容器 let activeReaContext = null; const contextStack = []; // 在函数执行前，把它登记为当前响应上下文 function runWithReaContext(fn) { // 压栈保存之前的上下文，恢复时使用 contextStack.push(activeReaContext); activeReaContext = fn; try { fn(); } finally { // 执行完毕后恢复之前的上下文 activeReaContext = contextStack.pop(); } } // 在 ReaValue 的 getter 里调用 function collectDependency(track) { if (activeReaContext) { track(activeReaContext); } }

为什么用栈而不是普通变量？因为可能出现嵌套的响应式上下文。比如一个更新函数里调用另一个被包裹的更新函数，如果只有一个普通变量，执行完内部函数后就会丢失外部函数的登记状态。使用栈结构后，进入嵌套函数前保存现场，退出后恢复现场，追踪关系才不会乱套。这个设计思路我在写第一版时没有采用，直到某次发现依赖丢失问题后才补上的，之后就没再出现过类似问题。

3.3 计算属性 ReaComputed 的实现：缓存与失效

有了依赖收集的基础，计算属性就水到渠成了。ReaComputed 做的事情有三步：持有计算结果、登记依赖、在依赖变化时标记失效。为了性能考虑，我不会每次读取都重新计算，而是用缓存机制——只有依赖变化之后，再次读取才会触发重算。

function createReaComputed(computeFn) { let cachedValue = undefined; let isDirty = true; // 缓存是否过期 const subscribers = new Set(); const recompute = () => { let result = null; runWithReaContext(recompute, () => { result = computeFn(); }); isDirty = false; cachedValue = result; // 计算结果变化后，通知订阅了该计算属性的视图更新 trigger(); }; return { get value() { collectDependency(track); if (isDirty) { runWithReaContext(recompute, () => { cachedValue = computeFn(); }); isDirty = false; } return cachedValue; }, // 内部通知 _dirty() { isDirty = true; Array.from(subscribers).forEach(fn => fn()); } }; }

这个实现的精妙之处在于“依赖收集发生在计算函数内部”。当computeFn执行时，它会读取若干 ReaValue，每个读操作都会把recompute登记为依赖。之后某个 ReaValue 发生变化，直接触发recompute；recompute执行完毕后再通知视图层更新。整个过程不需要手动声明“这个计算属性依赖哪些数据”，系统自己就知道得一清二楚。

3.4 微任务批量更新：一次数据变更只渲染一次

实际页面开发中，一个操作经常导致多个数据同时变化。如果每条数据变化都立刻触发对应视图更新，那么一次用户操作可能引发三四次 DOM 操作，得不偿失。所以“rea”里引入了批量更新的概念：把同步代码执行完后，在微任务阶段再统一触发视图刷新。

// 批量调度器的简化思路 const pendingJobs = new Set(); let isScheduled = false; function scheduleViewUpdate(fn) { pendingJobs.add(fn); if (isScheduled) return; isScheduled = true; Promise.resolve().then(() => { const jobs = Array.from(pendingJobs); pendingJobs.clear(); isScheduled = false; jobs.forEach(job => job()); }); }

这里有个很关键的点：用Promise.resolve().then()而不是setTimeout。因为微任务的执行时机在同步代码结束、DOM 渲染之前，而宏任务会在 DOM 渲染之后才执行。如果用setTimeout批量执行，用户在视觉上会看到“先闪烁再变化”的中间态，而微任务可以避免这个闪屏问题。在实际开发中，这个是影响体验感知非常明显的一个细节。

4. 实操过程与核心环节实现

4.1 完整代码：一个可以直接运行的 “rea” 最小实现

前面介绍了各个核心模块，下面我把它们组合成一个可以整体运行的最小实现。这段代码就是“rea”项目的核心部分，注释里包含了关键设计说明。不需要任何框架，打开浏览器控制台或者用 Node.js 都可以直接跑：

// ============ 第一部分：全局依赖管理 ============ let activeReaContext = null; const contextStack = []; function runWithReaContext(fn) { contextStack.push(activeReaContext); activeReaContext = fn; try { return fn(); } finally { activeReaContext = contextStack.pop(); } } function collectDependency(trackFn) { if (activeReaContext) { trackFn(activeReaContext); } } // ============ 第二部分：响应式数据 ============ function createReaValue(initialValue) { const subscribers = new Set(); let currentValue = initialValue; function track(observer) { if (!subscribers.has(observer)) { subscribers.add(observer); } } function trigger() { Array.from(subscribers).forEach(observer => { try { observer(currentValue); } catch (err) { console.error('订阅回调执行出错', err); } }); } return { get value() { collectDependency(track); return currentValue; }, set value(nextValue) { if (Object.is(currentValue, nextValue)) return; currentValue = nextValue; trigger(); }, get() { return this.value; }, set(nextValue) { this.value = nextValue; }, subscribe(fn) { subscribers.add(fn); return () => subscribers.delete(fn); } }; } // ============ 第三部分：计算属性 ============ function createReaComputed(computeFn) { let cachedValue; let isDirty = true; const subscribers = new Set(); function recompute() { const newValue = runWithReaContext(computeFn); cachedValue = newValue; isDirty = false; Array.from(subscribers).forEach(fn => fn(newValue)); return newValue; } return { get value() { collectDependency(observer => subscribers.add(observer)); if (isDirty) { runWithReaContext(recompute); } return cachedValue; }, subscribe(fn) { subscribers.add(fn); return () => subscribers.delete(fn); } }; }

4.2 视图绑定：把响应式数据连接到 DOM

光是数据响应式还不够，最终要落到视图上。“rea”的视图绑定函数非常简单，它接受一个 DOM 元素、一个选择器或一个文本节点，并在数据变化时更新其内容。考虑到安全和通用性，我默认只做文本节点的更新，不直接通过innerHTML渲染用户输入，这样能从根上规避 XSS 注入风险。

// 极简文本绑定器：适合普通文本和数字展示 function bindText(element, getValueFn) { element.textContent = getValueFn(); // 如果 getValueFn 依赖了响应式数据，这里要注册更新逻辑 const update = () => { element.textContent = getValueFn(); }; // 用响应上下文包裹一次读取，以收集依赖 runWithReaContext(update); return { update, destroy() { // 如果需要彻底解绑，可以在外部调用 } }; }

实际用起来是这样的：

// 计数器案例完整实现 const count = createReaValue(0); const displayEl = document.getElementById('display'); const btnEl = document.getElementById('increment'); // 初次渲染并自动订阅 bindText(displayEl, () => count.value); // 按钮点击时增加计数，自动触发上面的文本更新 btnEl.addEventListener('click', () => { count.set(count.get() + 1); });

这个例子虽然不到十行，却完整展示了“rea”的价值：bindText里传入的箭头函数读取了count.value，于是count就记住了这个更新函数。之后任何时候执行count.set()，更新函数都会自动被调用。 不需要手动去查 DOM、不需要写render()函数，数据和视图之间的连接在“读取时”就已经自动建立。

4.3 场景化应用：购物车小案例的完整推演

只有计数器还不过瘾，我再用一个更接近日常开发的场景来完整推演：“商品数量”联动“总价”。这个场景里有三个响应式数据：单价、数量、以及一个派生出来的总价。单价和数量的变化都会导致总价变化，而总价变化又会触发页面更新。

// 购物车总价计算案例 const price = createReaValue(59.9); const quantity = createReaValue(2); // 总价是计算属性：总价 = 单价 * 数量 const totalPrice = createReaComputed(() => { return Math.round(price.value * quantity.value * 100) / 100; }); // 模拟场景：商品单价发生变化 price.set(79.9); // 价格调整为 79.9 quantity.set(3); // 数量改为 3 // totalPrice.value 此刻自动变为 239.7

这里有一个很容易被忽略的细节：createReaComputed里使用了Math.round(... * 100) / 100来规避浮点数精度问题。我第一次写这个案例时直接返回price.value * quantity.value，结果页面上显示过239.69999999999998这种数字。这种问题在实际项目里很容易出现，所以计算属性里如果涉及金额，一定要做精度处理。

再把这个案例扩展到简化版购物车列表：每个商品行有数量输入框，删除按钮要能移除行，底部总价自动更新。用“rea”的写法，结构非常清晰——每行商品有一个数量 ReaValue，总价是一个遍历所有商品行数量后的计算属性。数量变化只需要quantity.set(newVal)，总价和结算按钮状态都会自动跟着更新，不需要手写任何联动逻辑。

4.4 典型错误与排查思路：五张实战排错表

在实际使用“rea”的过程中，我总结了五个最容易踩的坑，每个都是真实经历过才纳入的。下面用表格整理出来，方便大家遇到相似问题时快速对照。

第5个问题尤其容易出现。我在开发一个列表页面时，为每一行绑定了响应式更新，但用户跳转到详情页之后，那些回调仍然存在于 React 组件的闭包里，导致每次数据变化都会触发已经卸载的组件逻辑。后来我在所有subscribe调用处都严格要求“一点一线”——一个订阅必须配一个取消方法，并写入组件生命周期。

4.5 异步场景与批量更新实践

接口返回数据后再更新视图，是日常开发里最频繁的场景之一。举一个实际例子：一个搜索框，用户输入关键字后防抖 500 毫秒请求接口，接口返回后把结果渲染到列表中。用“rea”实现这个流程，关键点在于接口返回后执行set的动作：

// 搜索场景的响应式实现 const keyword = createReaValue(''); const searchResults = createReaValue([]); const isLoading = createReaValue(false); let timer = null; inputEl.addEventListener('input', (e) => { keyword.set(e.target.value); clearTimeout(timer); timer = setTimeout(() => { fetchSearchResults(keyword.get()); }, 500); }); async function fetchSearchResults(kw) { isLoading.set(true); try { const data = await mockSearchRequest(kw); searchResults.set(data); } finally { isLoading.set(false); } } // 视图绑定 bindList(searchResults.value); bindLoadingText(isLoading.value);

这里有个值得注意的心得：不要在fetchSearchResults里直接读取keyword.value然后手动处理后设置结果，而是让“搜索函数”自己成为一个响应上下文。如果需要搜索结果的派生状态（比如“共搜索到 N 条结果”），可以用另一个计算属性：

const resultSummary = createReaComputed(() => { const list = searchResults.value; const loading = isLoading.value; if (loading) return '正在搜索...'; if (list.length === 0) return '暂无结果'; return `共搜索到 ${list.length} 条结果`; });

每次状态变化，resultSummary 都会自动更新，搜索框、列表、提示文案三者之间的联动完全不需要手动管理。这种“零手写联动”的体验，用起来非常上瘾，也是“rea”能保持代码体积可控、逻辑清晰的最大原因。

5. 踩坑实录与经验内化

5.1 第一个教训：依赖收集必须发生在读取时

我在“rea”早期版本里犯过一个方向性错误——想通过“数据变化后遍历所有注册函数”来实现更新。结果遇到一个致命问题：更新函数里包含了大量条件判断，有些数据只在某个条件下才会被读取，如果不读取也要更新，那每次数据变化就会白白执行几十个无关函数。

后来我终于想明白：依赖信息是“读出来的”，而不是“注册出来的”。也就是说，系统应该记录的是“有哪些更新函数真的读了某个数据”，而不是“哪些函数可能想读”。这个“读取时收集”的思路是响应式框架的正确解法，也是 Vue 2/3 底层依赖追踪的核心逻辑。想清楚这一点之后，“rea”的实现变得清爽很多，连带性能也大幅提升。

5.2 第二个教训：批量更新的时机选择

批量更新里的微任务调度也是踩过坑才换来的经验。早期版本我直接用setTimeout(..., 0)来攒批更新，测试中偶尔会发现界面闪一下旧数据再变新数据。排查后确认，这是宏任务时机太晚导致的——浏览器已经把中间状态的 DOM 渲染出来了。

换成Promise.resolve().then()之后，所有数据变更产生的视图刷新都被压在同一个微任务队列里。在浏览器渲染新帧之前，DOM 已经更新到最终状态，用户完全感知不到中间变化。后来我理解了一个更本质的规律：凡是涉及“渲染前合并多次更新”的批处理操作，优先选微任务而不是宏任务。这个经验在自定义渲染器、编辑器架构里同样适用。

5.3 第三个教训：解绑与内存泄漏

订阅回调必须能取消，这是“rea”里几经波折后才固定下来的规范。早期版本我只实现了subscribe(fn)没有取消方法，开发时很爽，直接往订阅列表里丢回调，但久而久之页面越来越卡，内存占用只升不降。

后来我给每个subscribe/bind方法都加上返回值，规范里写死一条约定：谁订阅，谁负责取消。如果绑定是在组件挂载时做的，就在卸载时调用取消函数。实际开发中，我总结了三个容易遗漏解绑的场景：

• 列表进入详情页时，列表页自身的订阅忘记取消；
• 全局单例 store 里订阅了视图更新，视图销毁后订阅依然存在；
• 定时器内部调用了响应式数据的读取和更新，但定时器本身没清理。

5.4 常见问题速查表再补充

前面表格已经列出五个高频问题，这里再补充五个经验向的问题，属于“不报错但行为不对”的类型：

5.5 从“rea”到可扩展生态的方向

“rea”虽然小，但设计上预留了扩展空间。对我来说，一个有生命力的代码库不是功能堆得越多越好，而是核心逻辑稳定、边界清晰、扩展成本低。目前我基于“rea”继续做的方向有三个：

• 增加serialize和deserialize方法，让整个 Store 的状态可以一键存到 localStorage，页面刷新后自动恢复；
• 增加调试工具，劫持所有响应式数据的 get 和 set，把变化轨迹打印出来，方便排查“谁改了数据”；
• 增加面向类的写法适配，把createReaValue包装成可继承的基类，方便在业务代码里扩展定义好的领域模型。

这些方向并不复杂，篇幅也不会膨胀得很夸张。核心在于，“rea”的基础设计把最难的“自动依赖追踪”做完了，往上叠加功能就像在稳定地基上盖房子，踏实且安心。

6. 写在最后的实操心得

造“rea”这个轮子的整个过程中，我最深的感受是：很多前端概念听起来玄乎，真正动手实现一遍之后，会发现底层的逻辑朴素到几乎让你意外。响应式不过是“发布订阅”加“读取时收集依赖”的组合；计算属性不过是“带缓存的表达式”；批量更新不过是“在同一轮微任务里合并多次 DOM 操作”。知识如果只是停留在“用过框架”的层面，其实很难内化成自己的东西。只有亲手写过一遍、调试过一遍、踩过坑再补齐逻辑，才能真正理解那些框架在底层帮你扛住了什么。

我个人在实际使用中还有一个很实用的体会：如果你的项目里只是偶尔需要几个数据联动，完全没必要为了一两个页面引进重型状态管理工具。“rea”这种轻量方案，几十行代码，没有黑魔法，出了问题随时能断点调试，反而比大而全的框架更让人安心。当然，如果你已经在一个大型项目里用了成熟框架，也不建议为了“rea”去替换现有架构，工具之间没有绝对好坏，只有适配场景的差异。

最后再分享一个小技巧：如果你也打算自己写一个类似的小工具，强烈建议从一开始就把“解绑函数”的约定做进基础 API 里。不要觉得开发初期用不到，一旦项目进入中后期，清理订阅会成为你最频繁的操作之一。尽早定好规范，后面能少踩很多坑。希望这篇内容能给你带来一些启发，哪怕只是让你对响应式的原理多了一层理解，也算值得了。