1. 项目概述与需求拆解
先解释一下“rea”这个项目是什么。它是“Reactive Event Architecture”的缩写，是我用原生 JavaScript 在业余时间写的一个极简响应式渲染引擎，代号就叫 rea。核心功能很纯粹：把普通对象变成响应式数据，让页面根据数据变化自动更新，同时内置一套轻量的模板编译和组件挂载能力。简单说，就是一个「能跑起来的小型数据驱动视图框架」，体积控制在几 KB 以内，不依赖任何第三方库。
这个项目能解决的问题很实际：日常写页面时，我们经常只是需要一个数据绑定、一个组件复用，但引入一个完整的成熟框架往往意味着几百 MB 的依赖、一层又一层的抽象和黑盒。rea 要做的，就是把最核心的数据响应、模板解析和组件生命周期用最直白的方式写出来，让使用者能一眼看穿“数据改了之后视图是怎么变的”。它很适合三类人看：第一，前端开发者想理解成熟框架底层原理，不想只看博客上的流程图；第二，需要在极简环境或嵌入式场景中嵌入脚本的开发者；第三，正在带学生、带新人，想用一个最小可用系统来演示 MVVM 概念的技术人员。如果你是在评估生产项目选型，那我不建议你用 rea，它的定位从来不是替代成熟方案，而是把原理讲清楚。
1.1 rea 的由来与定位
这个项目的最初动机非常朴素。某天我把一个前端项目从代码仓拉下来，执行安装命令后，光依赖目录就占了接近 300 MB，我当时就在想：我不过是想做一个选项卡切换加一个列表筛选，为什么要为一个按钮背负一整个依赖树。于是决定花几个周末，自己写一套完全没有第三方依赖的轻量响应式框架，一方面验证自己对数据劫持、依赖收集、模板编译这些知识的理解，另一方面也确实想给“轻量”一个具体的量化标准。
rea 的定位我反复想过，最后定成三个：第一，教学演示工具，代码量适中，模块边界清晰，适合作为源码阅读的入门项目；第二，小组件渲染器，适用于那些不能用庞大构建链的页面，比如单文件 HTML 工具页、后台管理系统中的动态卡片、活动页中的局部区块；第三，个人框架原型，用来验证一些不常见的设计思路，比如细粒度依赖绑定在真实 DOM 场景中的表现。它不是全尺寸应用框架，所以从一开始就故意没有做路由、状态管理、服务端请求层，这些属于使用者自己组合的部分。
1.2 为什么还要自研一套，成熟方案不香吗
很多人听到“自研框架”第一反应就是重复造轮子。我的看法是：造轮子的价值不在于把轮子重新发明一遍，而在于搞清楚轮子为什么是圆的。成熟方案确实优秀，优秀到把复杂性隐藏得很好，但也正因为隐藏得好，当遇到性能问题时，大多数人只能凭借社区经验去猜测：是数据层级太多？是渲染频率太高？还是 diff 算法不够智能？这些猜测没有错误，但无法形成稳定的排查体系。
自己写一套之后，整个链条变成透明的：数据变化触发 watcher 的执行顺序、模板中每一个绑定点对应的依赖集合、组件销毁时哪些订阅还没有被移除，全部可以一步步断点追踪。这种能力的提升收益是长期的，哪怕之后回到成熟框架工作，遇到视图不更新、重复渲染、内存泄漏这类问题时，我至少知道应该从哪里入手，而不是在配置项之间来回试错。
自研方案在特定场景下还有现实收益。一是体积可控，rea 核心代码压缩后只有 5 KB 左右，对加载性能极度敏感的场景来说，这是一个可观的数字；二是行为可控，我可以在不破坏框架标准的前提下，给内部逻辑加自定义钩子，这在成熟框架中往往需要读源码、提 PR 或者 hack 私有 API；三是依赖面为零，没有传递依赖就没有供应链层面不必要的风险。当然，自研的代价也很明显：功能少、生态空白、需要自己维护，所以我对 rea 的期待永远是“够用、能懂、好玩”，而不是“全面、必胜、替代一切”。
1.3 技术选型：虚拟 DOM 还是细粒度绑定
这是 rea 在做架构决策时最关键的一个分岔路口。现在的成熟框架普遍采用虚拟 DOM 方案：数据变化后生成新的虚拟节点树，再和旧的虚拟节点树做 diff，计算出最小变更集合后才操作真实 DOM。这个方案的好处是抽象稳定，可以跨平台，可以批量更新；代价是算法复杂度和内存开销都不小，对一个目标体积只有几 KB 的项目来说，实现一版可用的 diff 算法会占据大量的代码空间，而且对新手阅读也不友好。
另一种方案是细粒度依赖绑定，也就是直接建立“数据 key 到更新函数”的映射关系。数据变化时，由数据系统亲自通知对应函数执行，不存在虚拟树的比较过程。生活化地讲，虚拟 DOM 的做法像是老师把全班作业收上来，逐本对比之后才指出哪一题写错了；细粒度绑定则是只盯着做错的那几道题，谁错就通知谁改。后者在节点数量少、变更频率中等的场景下，实现简单、更新精确、没有额外内存浪费，缺点是大面积数据变更时，会产生大量零散的更新任务，性能反而不如批量 diff。
rea 最终选择了细粒度绑定，原因有三。第一，代码量可控，整个响应式核心只需要 Observer、Dep、Watcher 三个角色；第二，教学价值更高，依赖收集和派发更新的过程可以直接用控制台追踪；第三，这些零散更新可以通过微任务队列合并，在下一帧统一处理，从而弥补批量更新能力。如果你要做的项目是复杂列表拖拽、树形编辑、大型表格这类高频交互场景，我不建议采用这种方案，虚拟 DOM 的批量 diff 能力更可靠。但如果是表单联动、状态卡片、局部区块刷新，细粒度绑定表现得非常干净。
2. 核心设计与原理拆解
2.1 响应式数据的三驾马车：Observer、Dep、Watcher
rea 的响应式系统由三个角色协同工作。Observer 负责把普通数据变成可观察对象；Dep 负责收集与某个 key 关联的 watcher 集合；Watcher 负责执行真正的更新任务。三者之间的协作流程可以归纳为“读取时收集，写入时通知”：当一个 watcher 执行渲染函数时，它会访问响应式数据，Observer 的 get 拦截器触发，把当前 watcher 记录到该 key 对应的 Dep 集合中；当对应 key 被重新赋值时，Observer 的 set 拦截器触发，通过 Dep 集合取出所有关联 watcher，逐个执行 update 方法。
我用 Proxy 来实现 Observer，而不是旧方案中常见的 Object.defineProperty。区别很重要：defineProperty 需要提前遍历对象的所有属性，并分别设置拦截器，这意味着对象新增属性天然无法被观察，数组索引变化也要做额外的补丁处理；Proxy 则是对整个对象做代理，get、set、has、deleteProperty 都能被统一拦截，新增和删除属性天然支持，代码结构上也更集中。
下面是一段简化的 observe 实现，展示了 Proxy 如何接入 track 和 trigger：
const targetMap = new WeakMap(); let currentWatcher = null; function observe(data) { if (data && typeof data === 'object') { return new Proxy(data, { get(target, key, receiver) { const result = Reflect.get(target, key, receiver); track(target, key); return result; }, set(target, key, value, receiver) { const result = Reflect.set(target, key, value, receiver); trigger(target, key); return result; } }); } return data; } function track(target, key) { if (!currentWatcher) 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(currentWatcher); } function trigger(target, key) { const depsMap = targetMap.get(target); if (!depsMap) return; const dep = depsMap.get(key); if (dep) { dep.forEach(watcher => watcher.update()); } }这里有一个关键设计：全局变量 currentWatcher。它标记了“当前正在渲染的 watcher”，这样当渲染函数访问响应式属性时，track 才能把这个 watcher 放进正确 key 的 Dep 集合中。如果没有这个全局变量，Observer 只能知道“某个 key 被读取了”，但不知道读取行为归属于谁，依赖关系就建立不起来。这个模式是理解响应式系统的核心，几乎所有细粒度响应式方案都遵循类似的约定。
Watcher 的实现也围绕这个约定：每次 update 时，先把自身赋值给 currentWatcher，再执行更新函数，更新结束后再清空。这里有个初学者很容易遗漏的问题：同一个 watcher 的依赖集合会在不同时间发生改变，如果在第一次渲染后新增了某个数据分支的访问，第二次 update 时旧依赖没有被清理，会留下过期订阅。完整的方案应该让每个 watcher 维护自己的依赖列表，并且在 update 前主动通知上一次的 Dep 集合移除自己，再重新收集。我在初版实现中偷了懒，结果踩了重复渲染的坑，后面第 4 章会详细展开。
2.2 模板编译：从插值占位符到真实 DOM
rea 的模板系统选择了一条相当务实的路线：不做完整的 AST 解析，而是用正则匹配加字符串替换来完成动态绑定。完整 AST 能处理复杂表达式、条件分支、循环嵌套，但代价是需要维护一整套词法分析和语法分析逻辑，对一个小框架来说性价比不高。rea 的场景是简单的状态展示和数据联动，用有限的正则规则满足需求就够了。
最基础的是插值语法。模板里写下 {{ message }}，编译器提取出 key 为 message，渲染时从 state 中取对应值替换。正则写法如下：
function compileText(template, state) { return template.replace(/\{\{\s*(\w+)\s*\}\}/g, (match, key) => { const value = state[key]; return value === undefined ? '' : value; }); }真正让模板“活”起来的不是替换本身，而是在替换时建立 watcher。rea 的做法是：一段模板在被挂载时，先用正则扫描出所有动态 key，然后创建一个渲染 watcher，让这个 watcher 在初次执行时读取所有 key 的值，从而自动完成依赖收集。此后任意一个 key 被修改，Dep 都会通知同一个 watcher 重新执行整段模板的编译和 DOM 更新。这个过程中，模板编译函数本身无状态，它对所有文本节点做一次 toString 级别的轻量处理，适合动态字段不多的小型组件。
指令系统我做了最小实现，只保留 v-model 和 v-if 两个高频场景。v-model 的处理思路是：编译时识别元素上的 v-model 属性，读取属性值作为数据 key，在元素上绑定 input 事件，每当用户输入就反向赋值给 state[key]；同时建立从 state[key] 到元素 value 属性的更新映射，实现外部修改也能回填到输入框。v-if 则更简单，它在编译结果里保留两块内容模板，根据条件真假切换渲染片段和移除片段。没有实现 v-for，因为数组渲染在细粒度绑定的机制上需要更精细的 key 追踪策略，我把它放在了后续规划里，避免第一版就把复杂度拉得太高。
2.3 生命周期钩子与事件系统设计
组件如果没有生命周期，最直观的问题是开发者在 DOM 还没挂载时去获取节点、或者在组件销毁后没有机会清理定时器和订阅，从而产生内存泄漏。rea 的生命周期只保留四个：created、mounted、updated、destroyed。created 在组件实例创建时触发，此时数据已经完成响应式改造，但尚未渲染到真实 DOM；mounted 在组件首次挂载完成后触发，此时可以安全地操作节点；updated 在每次 watcher 更新渲染后触发，适合处理需要依赖新 DOM 状态的后置逻辑；destroyed 在组件节点被移除时触发，清理工作都在这里做了。
事件系统没有沿用模板字符串里写 onClick 的传统方式，因为字符串模板无法安全引用组件作用域内的函数。rea 统一使用事件委托加事件映射表：组件定义时通过 events 配置声明事件处理函数，模板中用 on:click 这种格式标记事件名和元素，编译时给元素打上标记，事件绑定统一挂在组件根节点上，事件触发时根据元素标记查找并执行对应的处理函数。这样既避免了大量重复 addEventListener，也杜绝了字符串函数名的安全风险。这个设计和细粒度绑定有一个协同优势：事件处理器内部修改 state 时，响应式系统自动触发后续的渲染流程，开发者永远不需要手动调用 update 方法。
3. 实操过程：从零实现 rea
3.1 工程结构规划
动手写代码之前，我先把模块边界画清楚。整个项目分为四部分：observer 模块负责响应式数据代理；dep 和 watcher 模块负责依赖管理和更新调度；compiler 模块负责模板字符串编译和指令解析；component 模块负责组件生命周期、事件系统和挂载逻辑。目录结构如下：
rea/ src/ observer.js dep.js watcher.js compiler.js component.js index.js examples/ counter.html list.html form.html test/ observer.test.js compiler.test.js README.md之所以把 dep.js 和 watcher.js 拆成独立文件，是因为它们在概念上是两个不同角色。Dep 管理“数据到订阅者”的映射关系，Watcher 管理“订阅者自身”的执行逻辑和依赖元信息。初学者容易把它们合并，后期调试时就会很痛苦。模块之间保持单向依赖：observer 依赖 dep，dep 不依赖 watcher，watcher 在 update 时调用自身的执行函数。这样每一层都能单独测试。语言上我选择原生 JS，没有启用构建工具。对于一个几 KB 的项目，引入编译链反而是负担，直接用 script 标签加载几个源文件即可运行，浏览器控制台里也能直接做断点调试。
3.2 核心模块实现：observer、dep、watcher、compiler
先看 dep.js。Dep 本质上就是一个 Set 的集合，但在内部注意封装收集依赖和触发依赖的逻辑：
export class Dep { constructor() { this.subs = new Set(); } depend(watcher) { this.subs.add(watcher); } notify() { this.subs.forEach(watcher => watcher.update()); } }再看 watcher.js。Watcher 需要接受一个执行函数，并且在执行前后维护 currentWatcher 全局状态。为了让依赖清理成为可能，我还在 Watcher 上保存了“被收集进哪些 Dep”的引用。这个版本是修正后的完整版，包含依赖清理逻辑：
let currentWatcher = null; export class Watcher { constructor(updateFn) { this.updateFn = updateFn; this.deps = new Set(); } update() { this.cleanupDeps(); currentWatcher = this; this.updateFn(); currentWatcher = null; } addDep(dep) { dep.depend(this); this.deps.add(dep); } cleanupDeps() { this.deps.forEach(dep => dep.subs.delete(this)); this.deps.clear(); } }关键点在 cleanupDeps。每次渲染前，先把自身从所有旧的 Dep 集合中移除，然后重新执行 updateFn，在读取数据的过程中重新收集新的依赖。如果某个 key 不再被模板访问，它的 Dep 集合中就不会再留下这个 watcher，彻底避免过期订阅。这个设计解决了我在第 2 章提到的重复渲染隐患。
observer.js 与上一版相比多了一个细节：get 拦截器不再直接把 currentWatcher 塞进 Dep 集合，而是通过 watcher.addDep 方法完成，这样 Watcher 对象也能同步维护自身依赖列表。同时 Proxy 还需要拦截 has 和 ownKeys，确保 for...in 操作也能触发依赖收集，否则循环动态渲染在个别场景下会漏更新。
compiler.js 负责把模板字符串编译成可执行的渲染函数。我采用的策略是先扫描模板，提取所有 key 列表，然后生成一个渲染函数。渲染函数每次执行时，做三件事：替换插值、处理指令、返回最终的 HTML 字符串。下面对应的是插值编译器的最小实现：
export function compile(template, state) { return template.replace(/\{\{\s*(\w+)\s*\}\}/g, (match, key) => { const value = state[key]; return value === undefined ? '' : value; }); }实际使用中，运行时并不是编译一次就从模板字符串直接替换为静态 HTML，而是先挂载一个容器节点，在渲染函数执行时更新容器节点的 innerHTML。这种做法的好处是代码量小，坏处是整段模板都会重建，这会带来状态丢失，比如输入框正在输入时触发更新，会丢失焦点。rea 的应对策略是：真正需要保留状态的元素一律使用 v-model 指令，编译器会对这类元素做特殊处理，避免更新其 value 属性对应的整段 HTML。这个限制在 README 里写得很清楚：插值模板适合展示型内容，高频交互组件建议用 v-model 或事件绑定配合局部节点更新。
3.3 写一个可以运行的 Demo：计数器加列表
为了验证整个系统，我写了一个计数器加动态列表的 Demo。页面输入一个数字，点击按钮就加一；下面维护一个用户列表，输入名字并提交，列表新增一行。组件定义如下：
const app = createComponent({ template: ` <div> <p>当前计数：{{ count }}</p> <button on:click="increment">增加</button> <input on:input="updateName" /> <button on:click="addUser">添加用户</button> <ul> <li>{{ name }}</li> </ul> </div> `, data() { return { count: 0, name: '', users: [] }; }, methods: { increment() { this.state.count++; }, updateName(event) { this.state.name = event.target.value; }, addUser() { if (this.state.name.trim()) { this.state.users.push(this.state.name.trim()); this.state.name = ''; } } }, mounted() { console.log('组件挂载完成'); } }); app.mount('#app');实际上这里暴露了一个问题：插值模板中绑定的用户列表，如果列表数据变了，整段 ul 的 innerHTML 都会重建，虽然功能正确，但性能不是最优。这个 Demo 的价值不在于证明它能承受多大负载，而在于在控制台里观察依赖收集过程。我在 mounted 钩子里打印了 targetMap，可以看到每个数据 key 对应一个 Dep 集合，集合里维护了渲染 watcher。修改 state.count 时，只有负责显示 count 的模板片段触发更新，而列表部分的数据变更则是另一个 watcher 被执行。这种明细视图让我对整个响应式流程有了非常立体的认知。
3.4 性能与体积实测
我制作了一个简单测量脚本：渲染 500 个纯文本节点，然后批量修改其中 10 个数据 key，记录从数据赋值到 DOM 更新完成的时间。在普通浏览器环境下，rea 的细粒度绑定方案对 500 个节点的局部更新耗时基本稳定在 2 到 4 毫秒之间，表现非常优秀。但把场景换成一次修改 200 个 key，由于每个 key 都会触发各自的 watcher，即使做了微任务合并，更新时间也会上升到 15 到 20 毫秒，能感受到明显卡顿。这说明细粒度绑定的瓶颈不在节点数量，而在单次批量修改的 key 数量。
体积方面，rea 核心四个模块的代码总计约 8 KB，经过简单压缩后缩减至 5 KB 左右，gzip 后预计可以控制在 2 KB 以内。作为对比，这比一张中等尺寸的 JPEG 图片还要小，完全不需要考虑按需加载，直接内联到 HTML 里都没有问题。性能测试结果让我对它定位更清晰：rea 适合表单、仪表盘、内容卡片等以局部状态更新为主的场景，不适合大数据表格、实时图表这类高频全量更新的场景。
4. 实战排查：我踩过的五个典型坑
4.1 数据改了视图不更新，问题不在框架，在对象新增属性
初版使用 Object.defineProperty 时，给响应式对象新增一个属性，视图完全没有反应。这是 defineProperty 方案的固有限制：它必须在初始化时预先定义好每个属性的 getter 和 setter，新增属性时对象上根本没有拦截器。后来切换到 Proxy，这个问题在基础场景下消失，但新的问题来了：for...in循环读取时，Proxy 的 get 拦截器不会触发，因为引擎内部使用 ownKeys 操作，绕过 get 直接读取属性列表。所以我在 Proxy 上补了 ownKeys 拦截，对遍历行为也做了依赖收集，否则动态渲染数组时，push 一个元素后列表长度变了，但依赖列表长度的渲染函数不会重新执行。
排查此类问题时，我的经验是先分清两个层面：是数据层面没有修改成功，还是数据修改了但视图没有收到通知。控制台打印 state 对象，观察目标 key 是否真的被赋值；然后手动调用 trigger 对应 key，观察 watcher 是否执行。如果手动触发有效，说明依赖收集时 watcher 没有订阅到这个 key；如果手动触发也无效，那就是 watcher 本身没被注册进 Dep 集合，问题出在挂载阶段。
4.2 依赖收集错乱导致每次更新全量刷新
第一次整合系统时遇到了一个很诡异的问题：点击按钮只修改一个数字，但整个页面所有文本节点都在闪。我的第一反应是模板编译把所有 key 重名了，但检查后并非如此。真正的原因是初期 Watcher 实现里没有做依赖清理，而渲染函数每次执行时访问的数据范围在变化，旧依赖叠加新依赖，最终导致一个 watcher 误订阅了所有访问过的 key，页面任何数据变化都会把它唤起。
排查时我做了两件事：打印 targetMap 中每个 Dep 的订阅数量，以及打印每次渲染时 watcher 的执行堆栈。前者让我看到某个 key 下的 watcher 集合里有太多重复对象，后者则暴露了渲染函数里通过各种分支路径访问了太多额外数据。修复方案就是把依赖清理逻辑补上，也就是每个 watcher 更新之前，先将自身从所有旧 Dep 中移除，再重新收集。这个坑让我深刻理解了为什么大多数框架在 watcher 上维护一个依赖列表，而不仅仅用 Dep 记录订阅者。
4.3 组件销毁后仍然疯狂触发更新，内存泄漏的源头
场景是 tabs 切换时，我把旧面板的 DOM 移除了，但面板组件还在继续响应数据更新。原因是组件的渲染 watcher 仍然存在于某个 Dep 集合中，即使 DOM 节点已经不存在，update 函数依然会被调用，并且尝试对已卸载的节点做 innerHTML 更新，虽然浏览器不会报错，但浪费了大量计算资源。如果更新函数中还持有定时器、网络请求的回调，泄漏就会更严重。
修复方法是把 destroy 纳入组件生命周期的一等公民。组件卸载时，遍历它所有的 watcher，把 watcher 从所有 Dep 集合中移除，同时清除事件监听。为了简化，我给 Watcher 增加了一个 destroy 方法，内部调用 cleanupDeps 后把 updateFn 置空。这样即使 Dep 中还有残留引用，执行时也会被空函数拦截。这次修复之后，长时间切换页面，控制台的内存占用曲线变得平缓，问题才真正解决。
4.4 数组的 push 操作偶尔失效，和 length 属性有关
用 Proxy 监听数组时，push 本身会触发多次 set，包括新索引和 length 属性。但麻烦在于，渲染 watcher 如果同时订阅了数组的 length 和索引值，push 时会有两个 key 触发同一次更新，虽然不会数据错误，但会出现多余的重复渲染。我在模板里扫描 key 时，并没有区分数组 key 与普通属性，导致一个<li>{{ list }}</li>绑定会被记录为对 list 和 list.length 的双重依赖。
处理方法是做一层去重：当模板中访问的是一个数组属性时，只对数组对象本身建立依赖，长度变化由 push、splice 这些方法在处理时统一触发一次数组更新事件，而不是依赖 length key 的 set 拦截。这个调整让数组渲染从“每个变化都可能触发多次”简化成“每次方法调用触发一次”，调试时逻辑也清晰得多。
4.5 同一事件里修改多个数据，页面闪动和重复渲染
一次 click 处理函数中连续修改了三个数据字段。按最直接的实现，每次赋值都会触发 watcher 同步 update，页面会被连续更新三次，肉眼能看到闪烁。解决方案是引入批量更新调度器：watcher 的 update 方法不立即执行更新函数，而是把自身放入一个待执行队列，然后通过微任务统一触发清空。这样可以保证同一事件循环中多次数据修改只会产生一次渲染。
调度器实现思路很简洁，使用 Promise.resolve().then 作为微任务触发点；如果当前环境不支持微任务，可以降级到 setTimeout 宏任务。实测中微任务方案能保证在浏览器渲染前完成更新，页面只出现一次最终状态。对于交互密集的应用，这个优化带来的体感提升非常显著。这也是我后来检查“浏览器反复闪动”类问题时的固定排查方向之一：优先看是否有批量调度，再看 watcher 是否被误订阅了多个 key。
5. 测试、文档与后续扩展
5.1 单元测试怎么补，不引入测试框架也能自动跑
rea 的核心逻辑足够简单，完全可以脱离测试框架做单元测试。我写了一个几十行的断言脚本，读取测试文件中的用例，执行断言，输出通过和失败的数量。Observer 的测试用例覆盖三块：普通属性读取和修改、新增属性、for...in 遍历；Watcher 的测试用例覆盖依赖收集、依赖清理、重复更新合并；Compiler 的测试用例覆盖插值替换、v-model 标记、v-if 真伪分支。
以 Compiler 测试为例，用例大致是：
test('插值替换正确', () => { const state = { name: '张三' }; const result = compile('<p>{{ name }}</p>', state); assertEqual(result, '<p>张三</p>'); });这种轻量测试方式比起引入完整测试框架，降低了阅读门槛，也保留了核心回归能力。每次改动响应式核心后，我都会把测试脚本跑一遍，尤其是依赖清理和批量调度这两部分，它们是最容易在重构中被破坏的逻辑。测试的价值不在于证明代码没问题，而在于让你敢大胆改代码，不担心改坏之前已经验证过的行为。
5.2 示例目录维护与 README 写作经验
单有源码没有示例，项目基本上等于不可用。rea 的 examples 目录里每个示例都是独立 HTML 文件，打开就能用，方便新人对照。我在 README 里只写清楚三件事：第一，rea 是什么、能做什么、不能做什么；第二，如何在一个 HTML 文件里引入并创建一个组件；第三，和成熟框架的核心概念差异。示例代码保持在二十行以内，降低认知负担。
维护示例时最重要的原则是让每个示例只演示一个特性。计数器演示响应式数据和事件绑定，表单页演示 v-model 双向绑定，列表页演示数组渲染和生命周期。一旦示例混入多个特性，读者反而难以判断某个行为是哪个特性产生的。这对我来说也是一个很好的习惯：框架新增功能前先问自己，能不能用一个小示例把它说清楚，如果说清楚都需要写一百行，那这个特性一定过于复杂。
5.3 后续可能延伸的方向
rea 还有很多可以继续深挖的空间。第一个方向是服务端渲染，因为模板编译本身是纯字符串处理，天然可以复用到服务端，只需要把浏览器相关操作隔离到一个渲染适配层，保留模板编译和状态管理部分，就能输出 HTML 字符串。第二个方向是类型系统，给响应式数据增加对 TypeScript 类型定义的支持，或者做一个 JSON Schema 校验层，让数据错误在设计期而不是运行期暴露。第三个方向是跨端渲染，把当前适配真实 DOM 的渲染层替换成针对 Canvas 或终端字符界面的渲染器，核心数据逻辑完全不用动。
我不打算盲目扩展的方向也有两个。一是完整的虚拟 DOM diff 算法，因为细粒度绑定和 diff 是两个不同思路，强行融合会让代码复杂度暴涨，反而破坏目前清晰的架构；二是插件生态，对一个教学型框架来说，插件系统引入的抽象成本远超收益。后续我更希望把重心放在数组渲染的 key 追踪和模板表达式的安全解析这两个点上，它们能直接增强 rea 的实用场景。
最后再分享一点个人体会。写 rea 之前，我自认对前端框架的响应式原理非常熟悉，能画出一张漂亮的架构图。真正动手实现后才发现，画图时省略的那些细节才是一切坑的源头。依赖何时收集、何时清理、批量更新怎么合并、组件卸载如何断开订阅，每一个问题纸上谈兵都轻飘飘的，落到代码里都需要反复权衡。但这个项目给我带来的回报是实打实的：之后遇到任何数据驱动视图的问题，我都能快速定位到底出在数据层、调度层还是 DOM 渲染层。如果你也想试试自研一个袖珍框架，我的建议是从一个计数器开始，不要一开始就想做全功能，先把数据到视图的最小闭环跑通，再一点点往里加能力，过程中的收获会远超框架本身。
