企业官网建设流程全解析

第一次见到 rea 这个名字，是一个周末的深夜。当时我正在重构一个内部项目的列表页，页面逻辑不复杂，却因为状态同步问题改得身心俱疲。我需要的只是一个能自动把数据变化反馈到视图上的轻量方案，而不是把整包框架引进来。于是自己动手写了一个响应式绑定库，代号就叫 rea。这篇文章会把 rea 从设计到落地过程中最核心的思考、代码实现和踩过的坑都复盘一遍，适合那些已经有前端基础、想深入理解响应式原理的朋友，也适合准备自己封装一个小工具库的开发者参考。它不是那种“三分钟速成”的教程，而是把一个库从零到一的全过程讲清楚，希望能帮你在面对类似需求时少走弯路。

1. rea 是什么，以及它解决的真实痛点

1.1 一个小页面为什么会让我想自研状态层

先说背景。我维护的那个项目是一个老旧的运营后台，技术栈几乎算是“原生 JS + 手动渲染”。列表页面需要同时维护筛选条件、分页信息、选中状态、表格数据，以及弹窗里的临时数据。一开始我图简单，用一组全局变量存状态，每次操作后用render()方法手动更新 DOM。问题很快就暴露了：状态分散在各个地方，一个筛选条件变了，可能需要同时修改三四个变量，然后手动调用几次不同的渲染函数；如果漏了一次，界面上就会出现过期的数据。最要命的是，页面里还有很多像“当前选中行是否在可视区”这样的派生状态，每次都要临时计算，代码越写越乱。

这种场景下，大型状态管理框架虽然能用，但对这种不带构建体系的旧页面来说，引入成本太高：先是模块系统，然后是依赖转换，最后可能还要处理各种兼容问题。那时候我想要的其实特别简单：一个数据对象，修改它的属性，界面能自动跟着变化；最好还能顺手计算派生值，避免到处写重复的手算逻辑。这就是 rea 最初的雏形——不是要取代谁，而是为了解决一个具体、细碎但普遍的前端痛点：状态和视图的手动同步。

1.2 哪些场景适合 rea，哪些场景请绕道

经过一段时间的实践后，我总结出 rea 的适用边界。它特别适合中小型页面、工具型应用、老旧项目渐进式改造，以及那些不想引入完整框架的轻交互场景。在这些场景里，rea 能在不改变你原来的代码风格的前提下，用一个相对小的 API 面积解决响应式更新的问题。我后来在几个活动页和原型项目里也用了它，开发速度确实快了不少。

但如果你正在做一个超大单页面应用，内部有复杂的跨模块通信、嵌套路由、服务端状态缓存，那么 rea 这种轻量方案就不够用了。它本身没有设计路由、状态持久化、跨标签页同步这些能力，强行堆上去会让代码结构变得很别扭。还有一个不适合的典型场景：你的团队已经深度依赖某个框架，并且大量使用了框架自带的响应式体系，这时候再引入一套新的响应式模型，只会带来不必要的学习成本和心智负担。工具的价值在于匹配场景，而不是越全能越好。认清边界，比拼命堆功能更重要。

2. rea 的整体设计与核心原理

2.1 三个核心角色：Observer、Dep、Watcher

如果要用一句话说清楚 rea 的原理，那就是“数据变化时，找到所有依赖它的地方，逐一通知更新”。这句话听起来简单，真正落地需要三类角色协作。

Observer 负责把普通对象变成响应式对象。我的实现里，Observer 对对象的每个属性做递归劫持，利用Object.defineProperty或者Proxy拦截属性的读取和写入。读取时会把当前正在运行的依赖收集起来，写入时则触发通知。

Dep 是依赖收集器。每个响应式属性都对应有一个 Dep，或者按属性路径注册一个 Dep。它内部维护一个订阅者列表，也就是 Watcher 的集合。当属性被读取时，Dep 把当前 Watcher 添加进去；当属性被写入时，Dep 依次更新所有 Watcher。

Watcher 是真正的响应执行单元。它抽象出“谁依赖了这个数据”这个概念。在 rea 里，Watcher 可能是渲染函数、计算属性、侦听器，甚至是某个定时器的回调。Watcher 执行时会标记自己为“当前正在运行”，从而让 Observer 可以正确地把依赖收集到 Dep 中。

这三者的协作，构成了 rea 最基本的响应式闭环。这也是市面上很多响应式框架的理论底座。理解了这个模型，再去看 rea 的代码，就会觉得一切都是顺理成章的。

2.2 依赖收集到底在收集什么

我第一次设计 rea 时，最大的困惑是“依赖收集”到底是在收集什么。后来我理解到，核心是收集“函数执行环境”。

举个例子，我有一个计算函数total = price * count，它读取了price和count。当price变化时，我实际上需要重新执行这个函数，以便拿到新的total。所以price对应的 Dep 里应该存储一个 Watcher，这个 Watcher 包裹着这个计算函数。当price被修改时，Dep 就把这个 Watcher 拿出来执行一遍。

如果用全局变量window.__reaTarget来标记当前正在执行的 Watcher，那么依赖收集的过程就是：当函数第一次执行时，它访问了price，price的 getter 发现window.__reaTarget存在，就把它添加进自己的订阅列表。访问count时同理。这样，一次函数执行完成后，所有被读取过的属性都会记住这个函数对应的 Watcher。

这里有一个细节非常关键：依赖的收集一定发生在函数首次执行阶段。如果函数里有分支，比如if (cond)，而某个属性只在另一个分支里被读取，那么首次执行时该属性的 getter 没被触发，就不会被收集。后面即使那个属性变化，这个函数也不会重新执行。这不是 bug，而是“依赖收集”的正常规则——你只有读到了，才知道自己依赖它。这让我第一次真正理解了响应式系统的物理边界。

2.3 派发更新时的批量调度策略

如果一次修改连续改变多个属性，比如user.name = '张三'; user.age = 30;而页面渲染依赖了这两个属性，那么最理想的行为是只触发一次视图更新，而不是执行两次渲染。所以在派发更新时，rea 不会立即调用 Watcher 的更新方法，而是把更新动作放入一个任务队列，然后通过微任务统一调度。

具体来说，每个 Watcher 都有一个update()方法，它会把自身标记为入队。如果入队前已经在队列里，就忽略重复入队。入队完成后，通过 Promise 异步执行 flush。flush 时统一调用每个 Watcher 的run()方法，真正执行渲染或计算。这样，即使你连续修改了多个相关属性，一个 Watcher 也只会被真正执行一次。

这种批量更新的思路，有点像把消息通知合并成一次发布。它能显著减少不必要的重复计算，尤其在渲染逻辑复杂的页面时，性能提升非常明显。但也带来了新问题：你拿到的渲染中间态可能不是每次修改后的即时结果，而是一次合并后的最终状态。理解这一点，对于排查旧值、新值的问题很重要，我后面会专门讲。

3. 从零手写一个 rea 的最小可运行版本

3.1 搭建最小项目结构

动手之前，我先定义了 rea 的 API 面。为了保持简单，我选择做三个对外接口：observe(target)把对象变成响应式，effect(fn)让一个函数自动追踪依赖，computed(fn)返回一个带缓存的计算属性结果。这三个接口已经能覆盖我大部分业务需求。

项目结构上，我没有引入任何构建工具，直接用一个rea.js文件，使用 ES6 的Proxy实现响应式代理，避免处理Object.defineProperty对新增属性的兼容性问题。文件内部划分四个模块：Dep 类、Watcher 类、observe 函数、调度器。目录结构非常简单：

rea/ rea.js demo.html README.md

demo.html 用来做手动验证，rea.js 是核心实现。这种单文件结构很适合在小项目里直接引入，不需要打包器。如果你要发布成 npm 包，后续可以再加 rollup 或者 esbuild 做压缩输出，但最开始的时期，保持简单比工程化更重要。

3.2 实现响应式数据代理

我选择用Proxy而不是Object.defineProperty，核心原因是 Proxy 能拦截未知属性的读写，天然支持新增属性，而且不用预先遍历对象属性。

下面是一段核心代码，展示了如何把普通对象变成响应式对象：

const targetMap = new WeakMap(); function observe(target) { if (target === null || typeof target !== 'object') return target; if (targetMap.has(target)) return targetMap.get(target); const proxy = new Proxy(target, { get(obj, key, receiver) { const value = Reflect.get(obj, key, receiver); if (typeof key === 'string') { track(obj, key); if (value !== null && typeof value === 'object') { return observe(value); } } return value; }, set(obj, key, value, receiver) { const oldValue = Reflect.get(obj, key); const result = Reflect.set(obj, key, value, receiver); if (oldValue !== value) { trigger(obj, key); } return result; } }); targetMap.set(target, proxy); return proxy; }

这个实现里有一个细节：访问嵌套对象时，我会递归调用observe返回嵌套代理，这样可以保证深层属性也是响应式的。这里有一个潜在的性能问题：每次属性访问都创建一个新代理？不会。因为observe内部用了targetMap做缓存，同一个原始对象只代理一次，所以递归访问的性能在绝大多数场景是可控的。

3.3 实现 effect 与依赖收集

有了响应式对象，下一步是让函数能自动追踪依赖。实现的核心是使用一个全局变量来标记当前正在运行的 Watcher。

let activeEffect = null; const effectStack = []; function effect(fn) { const watcher = new Watcher(fn); watcher.run(); return watcher; } class Watcher { constructor(fn) { this.fn = fn; this.deps = new Set(); } run() { try { effectStack.push(this); activeEffect = this; this.fn(); } finally { effectStack.pop(); activeEffect = effectStack[effectStack.length - 1] || null; } } }

当 effect 中的函数读取响应式属性时，track函数会执行收集逻辑：

const depMap = new WeakMap(); // 原始对象 -> key -> Dep function track(obj, key) { if (!activeEffect) return; let depsMap = depMap.get(obj); if (!depsMap) { depsMap = new Map(); depMap.set(obj, depsMap); } let dep = depsMap.get(key); if (!dep) { dep = new Set(); depsMap.set(key, dep); } dep.add(activeEffect); activeEffect.deps.add(dep); }

这里的 Dep 直接用Set保存 Watcher 实例，其主要作用就是“集合”而已。真正重要的是依赖的收集时机和跟踪对象的维度：我用“原始对象 + key”作为 Dep 的唯一标识，这样当对象的某个 key 被写入时，就可以精确地找到对应的 Watcher 集合。

这里需要特别注意：track里使用的obj必须是原始对象，而不是代理对象。所以在observe的 getter 里，我用的是Reflect.get(obj, key, receiver)中第一个参数obj，也就是原始对象，这样track才能正确命中depMap。这个细节一旦写错，就会出现“数据变了但永远不触发更新”的诡异问题。

3.4 派发更新与批量调度

Watcher 被收集后，写操作触发更新时调用trigger，并配合调度器实现批量更新。

let queue = []; let flushing = false; function queueWatcher(watcher) { if (flushing) { if (!watcher.id && queue.indexOf(watcher) === -1) { queue.push(watcher); } } else { if (queue.indexOf(watcher) === -1) { queue.push(watcher); } } if (!flushing) { flushing = true; Promise.resolve().then(() => { const copy = queue.slice(0); queue.length = 0; flushing = false; copy.forEach(w => w.run()); }); } } function trigger(obj, key) { const depsMap = depMap.get(obj); if (!depsMap) return; const dep = depsMap.get(key); if (dep) { dep.forEach(watcher => queueWatcher(watcher)); } }

这里queueWatcher里最重要的一段逻辑是“去重”。同一个 Watcher 在同一个 tick 内只允许入队一次。因为修改多个数据属性时，它们可能把同一个 Watcher 触发多次，去重后能避免重复执行渲染函数。

需要注意的是，批量调度在异步任务中执行，如果你在修改数据后立刻读取视图，或者立刻检查某个 computed 的值，拿到的是更新前的旧值。这不是设计缺陷，而是所有响应式系统都会面对的时间差问题。正确做法是使用nextTick之类的机制，在队列 flush 之后再读取结果。

3.5 computed 与 effect 的扩展

有了 effect 和响应式代理，computed 的实现就顺理成章了。一个 computed 就是带缓存的 effect：它只在依赖变化时重新计算，并且计算后把结果缓存住，多次读取不会重复执行函数。

我实现 computed 时的思路是这样：computed 内部创建一个 Watcher，Watcher 在run()时计算值并保存到this.value。同时给 Watcher 加上dirty标志：依赖变化时把dirty设为 true，读取时如果dirty为 true 再重新计算，否则直接返回缓存值。这样保证 computed 不会在每次访问时都重复计算，性能很好。

function computed(fn) { const watcher = new Watcher(fn); watcher.dirty = true; deli: watcher 被收集时，依赖变化不会立即执行 fn，而是等别人读取它 const result = { get value() { if (watcher.dirty) { watcher.run(); watcher.dirty = false; } return watcher.value; } }; return result; }

这里有个坑：Watcher 运行后，它依赖的 Dep 中存的是 Watcher 实例，但 computed 的依赖变化时，Watcher 并不会主动重新执行。所以要让 Dep 通知时把 Watcher 的dirty设为 true。我是在 Watcher 里加了一个update()方法，默认情况下update()直接入队重新执行，而用于 computed 的 Watcher，其update()方法只把dirty设为 true 并调用父级依赖的更新。这一点可以根据实际需求微调，但核心思想就是“延迟计算、按需缓存”。

4. rea 在真实业务场景中的接入经验

4.1 与原生 DOM 操作混用时的注意事项

rea 最大的优势是你能在已有项目中逐步引入，不用一次性推倒重写。但它和手写 DOM 操作混用时，有一些常见的冲突点。我踩过的最典型的一个坑是：我使用 rea 管理数据，一个合作伙伴的模块里却用innerHTML直接重写了某个容器。这个容器原本是由 rea 渲染出来的，重写后 rea 的数据和视图就脱节了——后续响应式数据一变，视图刷新函数仍然会尝试重绘这个容器，但容器里的内容已经不是我预期的结构，导致渲染结果错乱。

我的解决原则是：用 rea 管理的区域，尽量不要直接用原生方法去改它的 DOM 子树。如果确实需要和外部组件协作，就给外部组件划分一个独立容器，让 rea 只负责它自己渲染的那部分。如果你希望 rea 渲染结果也能被外部操作接管，那么最好在外部操作后手动调用一次依赖数据的trigger来同步视图。但在项目里，我建议还是通过“数据中转”来维护一致性，这样代码更纯粹，排查问题也更容易。

4.2 性能优化：什么时候需要手动拆分更新

rea 的批量更新可以减少重复渲染，但如果你在一个很大的响应式对象里，频繁更新其中一个字段，每次更新依然会触发所有依赖这个字段的 Watcher。这在大型表格或长列表场景里会成为瓶颈。

我实际遇到的需求是一个表格组件，它监听一个巨大的表格数据对象。我最初把整个表格数据对象作为单一响应式对象，每行数据都是其属性。结果修改一行中的某个单元格时，视图更新函数会因为依赖了整个对象而重绘整张表格。后来我把每行数据拆成独立的响应式对象，让每一行的渲染函数只收集自己这一行的依赖。这样修改某一行的一列时，只会更新那一个单元格对应的 Watcher，性能提升非常明显。

这个优化思路其实很通用：不要把“所有数据”都放在同一个响应式对象里，要让响应式粒度贴近你的视图粒度。如果你的页面有多个相对独立的板块，比如筛选区、列表区、详情区，那就把它们的 state 分开管理，而不是塞进一个大对象。响应式粒度越细，无谓的渲染就越少。

4.3 在现有工程化项目中的按需引入方式

如果你要在一个使用 webpack 或 vite 的工程里引入 rea，并不需要把整个库全量打包。由于 rea 是单文件、无依赖的库，可以直接在package.json中声明一个对./src/rea.js的本地引用。更合理的做法是把 rea 的核心代码提取为一个独立 package，然后通过 npm link 或 file: 协议引用。

当然，如果你只是想在老项目里快速试一下，也可以直接<script src="./rea.js"></script>引入，然后挂载到全局。rea 整体只有几百行代码，不会带来体积上的压力。但要注意的是，如果页面本身使用了 ES6 语法而你还没有 babel 转译，你可能需要把 rea.js 转换成 ES5 后再引入，或者使用对应的 IIFE 版本。

我在实践中的习惯是把 rea 作为独立的本地模块维护，也会为它写一个简单的api.md文档，记录每个 API 的输入输出和边界条件。这个小习惯帮我节省了大量回溯时间，尤其是在项目持续迭代之后。

5. 常见问题与排查实录

5.1 循环依赖导致栈溢出

我最早把 rea 的 watch 逻辑做得比较激进：一个 Watcher 执行时，如果它依赖的某个属性也间接依赖同一个 Watcher，就可能形成循环。典型场景是：effectA读取了 A 和 B，effectB读取了 C，而 C 的 getter 里又读取了 A。执行effectA时，会触发 C 的读取，而 C 的 getter 又读取 A，最后在 A 的 getter 里发现当前运行的 Watcher 还是effectA本身，再把effectA加进 A 的依赖集合。这样effectA和 C 之间形成了环，更新时互相触发，最终栈溢出。

排查这类问题的最好方法是在track函数里做一次判断：如果当前 Dep 已经包含 activeEffect，就不再重复添加。但更根本的解法是，在业务层尽量避免形成这种循环依赖。如果确实不可避免，就要调整数据结构，让派生数据之间是单向依赖关系，而不是互相依赖。我后来给 rea 增加了依赖树的打印方法，用日志定位到底是哪些属性形成了环，大大提高了排查效率。

5.2 数据更新了但视图不刷新

这是响应式系统最常见的疑难杂症。我遇到过的原因有好几类，这里分享最常见的几个。

第一，你读取属性时使用的是代理对象还是原始对象。如果你不小心用原始对象参与计算，那么原始对象没有 getter 拦截，就不会触发 track。解决方法是统一使用observe返回的代理对象读取数据。

第二，你写入的属性根本不是响应式属性。如果你在observe之后给对象添加了一个全新的 key，但你的 observe 使用的是Object.defineProperty而不是Proxy，这个新 key 就不会被劫持。虽然 rea 默认用 Proxy，但如果你在某个版本里为了兼容性用了 defineProperty，就会踩这个坑。建议：如果不要求老浏览器，直接放弃 defineProperty。

第三，Watcher 的依赖没有被正确重新收集。比如你的渲染函数里有条件分支，首次执行时某些属性没有读取，后来数据变化导致分支切换，但那些属性不在依赖集合里。这时候需要强制刷新一次依赖，或者确保依赖收集的覆盖范围足够广。这也是我后来把模板编译阶段的所有可能分支都生成一次访问的原因之一。

5.3 批量更新导致的旧值问题

由于 rea 的更新是异步批量处理的，有时你在修改数据后立即读取依赖该数据的其他属性，会拿到更新前的旧值。这不是 bug，而是异步特性带来的时间差。比如：

const state = observe({ count: 0 }); effect(() => { console.log('count is', state.count); }); state.count = 1; console.log(state.count); // 这里的 count 会是多少？

如果是立即读取，state.count已经变成 1，因为代理对象的 set 是同步的。但effect的视图更新函数是异步执行的，所以日志输出顺序可能不是你直觉里的顺序。如果业务里确实需要在一次修改后立即读取更新后的 DOM 或 computed 结果，我建议在 rea 里提供一个类似nextTick()的方法，把后续操作排在 flush 之后执行。我的实现里直接用了Promise.resolve().then(...)，所以只要在你的代码之后用await nextTick()即可。

5.4 内存泄漏排查

响应式系统的内存泄漏，多数都发生在没有正确清除 Watcher。比如你在一个弹窗组件里创建了一个 effect，弹窗关闭后，这个 effect 仍然存在，并且还被页面上的某些响应式依赖持有，导致无谓的运算。更麻烦的是，如果这些依赖链中还引用着 DOM 节点，最终会导致整个弹窗 DOM 无法被回收。

我的解决方案是为 Watcher 提供dispose()方法，它会遍历并清空所有已绑定的 Dep 集合，从每个 Dep 里移除当前 Watcher。同时我要求所有创建 effect 的地方，在组件销毁时必须调用dispose()。实践下来，这个要求在早期经常被忽略。后来我封装了一个生命周期管理工具，统一监听页面卸载或组件销毁事件来调用清理逻辑。这套机制做好之后，我在一个连续操作 2 小时的活动页上测过内存占用，增长曲线变得平稳，没有再出现明显的泄漏。

5.5 实际操作中的 debug 技巧

最后分享几个我在排查 rea 问题时经常用的 debug 方法。第一，在track和trigger里加上条件打印，输出当前操作的对象 key、Watcher 编号，能直观看到依赖收集和派发更新的链路。第二，为每个 Watcher 起一个名字，或者给自定义fn绑定一个name，在日志里能认出是哪一个渲染任务。第三，我会用performance.mark和performance.measure记录每次 flush 的耗时，快速定位哪些 Watcher 拖慢了渲染。这些方法不复杂，但确实能大幅提升排查效率。

如果你也打算自己写一个类似的响应式工具，我的建议是不要一开始就贪大求全，先把observe、effect、computed这三个接口做到稳定，再慢慢扩展 watch、数组方法、模板编译等能力。rea 这个项目到目前也没有做很多花哨功能，但它在多个真实页面里稳定运行了很长一段时间。我个人的体会是：一个库能不能撑起业务，不在于它有多全，而在于它把你最需要的那几个能力做透。遇到不合适的场景，不妨勇敢地砍掉；遇到使用的纠结，就回头想想“数据变化后，谁需要知道”这个根本问题。保持简单，就能走远。