如果有人只丢给你一个词——“rea”没有需求文档没有设计稿没有预算限制你会怎么反应我第一反应是对方在开玩笑。但冷静下来这反而成了我最近挺过瘾的一个项目把“rea”从一个模糊代号逐步做成一个能跑在浏览器里的轻量级前端渲染引擎。别看这个代号短它背后要考虑的东西并不比一个完整项目少。这篇文章我会完整记录我是怎么从零开始拆解这个需求、选择技术路线、设计渲染链路的以及中间踩到的那些常规文档里根本不会写的坑适合对前端框架原理感兴趣、或者想尝试自己造一个小轮子的朋友当参考。1. 只有代号“rea”时我先做的不是写代码而是这三件事1.1 先搞清楚“rea”到底可能是什么接到这种只有代号的输入第一反应不是猜而是把所有可能的含义列出来。我自己列了几种rea 可能是 React 的截断式命名很多工具都这么干比如把 application 截成 app把 library 截成 lib。它可能是 render 的前三个字母说明它跟渲染层关系很深。也可能是 REAResource Event Agent领域建模的缩写那是另一种完全不同的话语体系主要用在业务建模和会计系统设计上。当然也可能是谁随手敲出来的几个字母本身没有任何含义。不同解读会通向完全不同的设计。我没有急着拍板而是把“rea 是什么”这个问题转换成“我希望它是什么”。既然没有外部约束我就给它一个对自己最有价值、也最有通用性的设定一个迷你前端渲染引擎。这个引擎要自带组件模型、声明式视图和虚拟 DOM diff相当于一个简化版的框架核心。目标是把“声明式 UI 是怎么跑到真实页面上的”这件事彻底弄明白。1.2 定义边界哪些功能必须有哪些坚决砍掉有了方向后我给 rea 划了一条很清楚的边界线必须有JSX 语法支持一个完整组件树组件状态和全局状态的管理能力一套可视为“渲染到真实 DOM 之前中间层”的虚拟节点结构当状态变化时能精准更新对应的真实 DOM而不是全页面重建在渲染任务较重时能主动让位给用户交互坚决不做不做服务端渲染不做路由不做样式隔离不做完整的依赖收集/响应式系统有些功能看起来很有诱惑力比如响应式系统听起来“很高级”但每加一个学习成本就指数上升。这个边界让我能在一个相对短的时间内走完“从编译到渲染再到更新”的闭环而不是把时间耗在旁支功能上。1.3 为什么边界比功能更重要很多小型项目夭折不是因为功能不够而是因为什么都想做。把 rea 定为一个“以学习为目标的最小引擎”之后所有技术决策都有了判断标准。比如有人可能想上 TypeScript但为了减少一层编译复杂度我在第一版用了纯 JavaScript 的 JSDoc 标注比如有人可能想直接上 vite但为了看清楚 JSX 翻译过程我保留了手动编译这一步。边界一旦清晰纠结自然就消失了。这个阶段我学到的东西其实跟写代码没有关系纯粹是关于“如何管理自己的贪心”。2. 为什么不直接引入框架偏要自己造一个简化版2.1 套框架时你失去的东西我自己是每天都在用成熟框架的人并不反对框架。但如果你想把“状态变化如何变成页面变化”讲清楚框架的封装反而成了障碍。框架帮你把脏活干好但也把关键路径藏起来了。直接看框架源码也是一条路但成熟框架动辄几十万行里面包含了运行时兼容、不同平台适配、性能优化黑魔法新手很难分清哪些是核心原理、哪些是工程妥协。自己从零写一个 rea 类似物等于是把核心路径亲自走一遍复杂度完全由自己控制。2.2 rea 的路线选择下表是我在动手前做的技术路线对比候选方案优点缺点我的选择直接使用成熟框架稳定、文档全、生态好原理隐藏在抽象层学习成本高否学习项目不需要阅读源码加笔记成本低能接触真实实现容易被细节淹没难以体系化否缺少动手验证自研轻量渲染引擎完全可控能验证每个假设需要投入时间有踩坑风险是这张表可能看起来像废话但真正重要的是最后一行背后的心理建设我会反复跟自己说这不是重复造轮子而是为了验证一个假设——“一个只有完整框架三分之一复杂度的引擎能不能覆盖绝大多数声明式 UI 场景”。如果能说明框架里很大一部分复杂度是为极端场景准备的这对我们日常做技术选型是有参考价值的。毕竟你平时在项目里决定“要不要引入这个大库”本质也是在做类似的取舍。2.3 rea 最终确定的架构组成rea 的代码结构只有四块createElement负责把 JSX 编译产物转换成普通对象。render负责从虚拟节点生成真实 DOM并挂载到容器。reconcile负责比较新旧虚拟节点找出差异并执行真实 DOM 的最小修改。scheduler负责把渲染任务拆分成小块避免长时间阻塞浏览器主线程。四块加起来第一版核心代码只有一千行出头。这个行数说明一个问题框架的“核心思想”其实不复杂复杂的是各种边界条件和配套生态。比如错误处理、服务端渲染、并发特性、设备兼容这些都会把代码量迅速推高。所以不要被“框架源码那么庞大”吓到你只需要抓住骨架其余的都是肉。3. 渲染链路我是怎么把 JSX 变成真实 DOM 的3.1 JSX 编译后到底是什么如果你没用过 Babel 的插件可能不知道 JSX 不会直接进浏览器。它会被编译成 createElement 的函数调用。比如const vnode div classNameboxhello rea/div编译后会变成const vnode createElement(div, { className: box }, hello rea)每个 JSX 节点本质上就是一个配置对象。要写一个前端渲染引擎第一步就是把 createElement 做成一个“只返回普通对象、绝不直接操作 DOM”的纯函数function createElement(type, props, ...children) { return { type, props: props || {}, children: children } }很多人会不理解为什么要绕这么一层直接 document.createElement 不是更快吗因为虚拟节点是“未来状态的描述”它不持有真实 DOM 的引用所以可以随时重建、随时丢弃。只有到了 commit 阶段才把最新描述翻译成真实 DOM 操作。这个分离是所有声明式 UI 的地基。3.2 虚拟节点的形状除了 type 和 children 还需要什么随着项目推进我发现自己还需要给节点加两个“元信息”字段。第一个是 key用于在列表更新时识别“哪个节点对应哪个数据”。第二个是 index用于在同层对比时减少查找时间。这其实是完整框架里的 fiber 结构的一个极简版真正框架里每个节点还串联了 alternate、return、sibling 等等我全部砍掉了只保留当前节点需要的字段。砍掉之后diff 算法从“树上递归”变成了“同层数组扫描”复杂度简化非常多但代价是跨层级的节点移动不会做最优复用。这个问题我一开始很纠结后来发现绝大多数业务更新都是同层的跨层移动节点的场景很少见就算见了性能损失也就是一次节点重建不会带来逻辑错误。3.3 diff 的三个规则我的 diff 只做三件事每条规则背后都有明确理由类型不同直接替换整个节点。因为不同类型意味着结构和状态完全不同保留 node 没有意义。比如一个 div 变成了 button你总不能硬把 div 的属性挪过去。同类型复用真实 DOM 并更新属性和 children。注意是“复用”而不是“重建”这是 diff 能省性能的核心。真实 DOM 创建和插入是最贵的操作复用能省下大头。列表更新时先用 key 找到旧节点对应的位置找不到就当新增处理。这套规则是完整框架 diff 的书面总结。如果你去读成熟框架的源码会发现 diff 会复杂得多确实如此但 rea 的逻辑控制在三句话之内反而容易验证。实现时唯一要小心的就是“更新属性”的方法因为 className、style、事件监听器这三类的处理方式完全不同。我自己写了一个 setProps 函数每次进入都先清掉旧事件再挂新事件虽然代价是事件绑定会比原生频繁但换来的是不会出现幽灵监听器问题。这个取舍在两三万个节点上才会有点性能影响普通页面完全无感。4. 调度器让渲染像我欠了用户债一样排队执行4.1 为什么一个“只有一千行”的引擎也需要调度器当列表有几千个节点时一次状态更新如果被同步执行整棵树的 diff 和 DOM 操作会占据浏览器主线程很久用户会感觉到输入延迟或者动画卡顿。调度器的核心职责就是把原本一次性做完的大任务拆成多个小块在浏览器空闲时间做。这跟搬货很像——你不会一侧身就把所有货全搬到楼下你会一次搬几箱搬完一箱看看电梯门有没有要关的意思。浏览器给我们的工具是 requestIdleCallback它会等当前帧的空闲时间到了才回调。rea 的调度器在第二版才加上第一版打开一个一万节点的列表输入框敲一个字能卡接近一秒加上调度器之后卡顿基本消失。这个体验对比远比任何性能测试数据都有说服力。我当时的感受是自己实现了之后才真正理解为什么主流框架要把调度器做成核心能力因为它直接决定了应用在复杂页面上的“手感”。4.2 调度器的最小实现我实现了一个约 60 行的任务队列let tasks [] let isScheduled false function schedule(task) { tasks.push(task) if (isScheduled) return isScheduled true requestIdleCallback(flush) } function flush(deadline) { while (tasks.length 0 deadline.timeRemaining() 1) { const task tasks.shift() task() } isScheduled false if (tasks.length 0) { schedule(() {}) } }这个实现有个关键缺陷requestIdleCallback 在部分环境下可能一直不触发导致任务被无限拖延。我后来加了一个兜底如果三帧约 50ms内没有空闲回调就直接用 setTimeout 强制执行剩余任务。优先级降级逻辑也是在同样位置加的输入相关的更新可以排队等待但不能被饿死。这里我没有用 requestAnimationFrame 做调度因为它偏向动画时间线而渲染任务需要的是“空闲时间”两者目标不一样混用反而容易出问题。4.3 级联更新和优先级调度器带来的隐藏收益给 rea 加了调度器之后我顺手实现了两个之前一直不敢碰的功能。第一个是级联更新——一个组件状态变化导致另一个组件状态变化在同步模型里可能引发渲染递归在调度模型里变成了普通任务入队天然避免了栈溢出。第二个是让“高优先级任务插队”比如输入框的更新永远排在列表重排前面。这个能力在第一版纯同步渲染里几乎不可能优雅实现但在队列模型里就是多一个 sort 或者 unshift。所以我的感受是调度器不是性能加分项而是一个引擎从玩具走向可用的分水岭。没有调度器引擎只能在“小页面”上自娱自乐有了调度器才敢把它放到真实数据量的场景里。5. 状态管理订阅、批量更新和闭包陷阱5.1 状态应该挂在哪一层刚开始我直接把状态放在每个组件内部后来发现全局状态比如用户信息、主题色在跨组件共享时非常痛苦。rea 最后采用的结构是组件局部状态挂在组件自己的闭包里全局状态放在一个独立的 store 对象里任何组件都可以通过 subscribe 订阅 store 的变化。这种模型简单到没什么值得炫耀但它让我更理解一件事状态管理的第一要务不是“让更新更快”而是“让更新的路径可预测”。只要路径可预测问题就好排查。如果你把状态这里放一点、那里存一份最后连“这个值是从哪来的”都说不清楚那再快的状态库也救不了你。5.2 批量更新的实现如果用户在事件处理函数里连续调用几次 setState每次都触发渲染会造成大量重复 diff。rea 的做法是把 setState 的触发逻辑改成异步刷新状态先合并到一个队列中等当前同步代码执行完再一次性进入渲染阶段。let batchQueue [] let isFlushing false function setState(patch) { batchQueue.push(patch) if (isFlushing) return isFlushing true Promise.resolve().then(() { Object.assign(store, ...batchQueue) batchQueue [] isFlushing false renderApp() }) }这看起来简单但里面有个容易被忽略的点如果你在事件处理函数里依赖于 setState 之后的 store 值读取读到的是旧值因为它要等微任务才合并。很多人会在这里踩坑。解决方案是 setState 直接返回合并后的快照或者提供 getState() 供你在同一个微任务里读最新值。rea 选择了后者因为 getState 是一个显式动作更符合直觉。批量更新这个设计我也不是一开始就明白是写完同步渲染后自己在控制台实验连续三次 setState 时发现页面被渲染了三遍才回头加上去的。5.3 闭包陷阱我的一个真实翻车现场我在写一个倒计时组件的时候用了这样的代码function useCountdown(seconds) { const [count, setCount] createState(seconds) useEffect(() { const timer setInterval(() { setCount(count - 1) }, 1000) }, []) return count }这个count是 effect 创建时的值永远等于初始 seconds。因此 setCount 每次都在设置同一个值倒计时纹丝不动。这个 bug 我排查了很久因为控制台打印的 count 看起来每次都不同——其实打印的是组件重新渲染时的值而不是 effect 闭包里的值。解决方式是 setCount 支持函数式更新setCount(prev prev - 1)。这个经历让我明白闭包陷阱不是某个框架独有的而是所有用闭包保存状态的方案都会遇到的问题。rea 的第二版开始我强制自己写任何异步更新都用函数式写法这才把这类 bug 从根上踢掉。6. 测试结果、那些反直觉的发现和给后来者的建议6.1 与原生 DOM 操作和全量重建的对比我在本机用一个 5000 行表格做了一组对比测试结果如下更新场景全量重建删掉全部再插入rea diff 更新原生手动 DOM 更新修改 1 个单元格71ms4ms1ms修改 100 个单元格75ms12ms9ms表格行排序82ms18ms无法直观估测结果里有两点出乎我的意料。第一修改 1 个单元格时rea 的 diff 比原生慢因为要遍历整个虚拟 DOM 树找差异原生是直接定位。第二行排序这种场景rea 的胜出非常夸张原因是全量重建把 DOM 从无到有再造了五千次而 diff 只做了几十个节点的移动和更新。这说明 diff 的价值不在“每一次操作都更快”而在于“无论业务逻辑多复杂更新代价都维持在一个低且稳定的量级”。这个稳定性正是声明式 UI 最大的工程价值。6.2 三个反直觉的实测结论第一小列表少于 200 个节点直接重建比 diff 更快。diff 的前置遍历成本虽然不高但仍然存在。所以我给 rea 加了一个阈值节点总数小于阈值时直接跳过 diff走全量重绘。第二key 如果写错性能可能比不写更差。不写 key 时引擎用 index 做标识状态错乱是隐性摸不到的写了错误 key引擎会在 diff 环节多做大量无效匹配性能下降非常明显。这也是我在真实项目中最容易看到的问题。第三调度器在低端设备上反而容易让渲染看起来变“慢”因为任务被拆碎后中间状态会闪现。rea 的处理是只对“耗时超过 16ms 的大任务”启用时间切片小任务还是同步执行既不阻塞也不会闪烁。6.3 给想复刻 rea 的人的一些建议如果看完你也想自己写一个类似的迷你渲染引擎我的建议有三条。第一第一版千万不要加调度器先把同步渲染跑通感受一下它有多卡再回头加调度你会对必要性有最真实的体感。第二所有状态更新都必须走统一入口不要在业务代码里直接操作 DOM否则后期排查成本会高到你怀疑人生。第三写测试时优先覆盖三类用例列表增删、组件卸载时的事件清理、以及 effect 里异步更新。这三类用例基本能覆盖我踩过的全部坑。我在 rea 这个模拟项目里的定位始终是“学习验证器”而不是“生产替代品”如果你想要的是生产级的完美框架那直接看成熟框架源码会是更高效的路。最后说点个人的体会。rea 这个项目最大的收获不是那一千行能跑的代码而是让我在写每一块功能之前都学会了先问一句“这东西要是没有的话会发生什么”。很多模块听起来是必备的比如调度器、函数式更新实际上没有它系统也能跑只是会在特定场景暴露出问题。真正核心的往往是那几条最朴素、最容易被忽略的链路。到现在我还在给 rea 加新东西比如高阶组件和错误边界每次加之前还是会用同样的问题先问自己一遍。如果你手头也有一个这样模模糊糊的代号不妨也一样别急着写功能先把边界和动机想清楚后面会顺很多。 
长河君 · 2026/10/20 6:51:33 · 阅读 1.2k 从零手写迷你渲染引擎rea：深入理解虚拟DOM与diff算法
如果有人只丢给你一个词——“rea”没有需求文档没有设计稿没有预算限制你会怎么反应我第一反应是对方在开玩笑。但冷静下来这反而成了我最近挺过瘾的一个项目把“rea”从一个模糊代号逐步做成一个能跑在浏览器里的轻量级前端渲染引擎。别看这个代号短它背后要考虑的东西并不比一个完整项目少。这篇文章我会完整记录我是怎么从零开始拆解这个需求、选择技术路线、设计渲染链路的以及中间踩到的那些常规文档里根本不会写的坑适合对前端框架原理感兴趣、或者想尝试自己造一个小轮子的朋友当参考。1. 只有代号“rea”时我先做的不是写代码而是这三件事1.1 先搞清楚“rea”到底可能是什么接到这种只有代号的输入第一反应不是猜而是把所有可能的含义列出来。我自己列了几种rea 可能是 React 的截断式命名很多工具都这么干比如把 application 截成 app把 library 截成 lib。它可能是 render 的前三个字母说明它跟渲染层关系很深。也可能是 REAResource Event Agent领域建模的缩写那是另一种完全不同的话语体系主要用在业务建模和会计系统设计上。当然也可能是谁随手敲出来的几个字母本身没有任何含义。不同解读会通向完全不同的设计。我没有急着拍板而是把“rea 是什么”这个问题转换成“我希望它是什么”。既然没有外部约束我就给它一个对自己最有价值、也最有通用性的设定一个迷你前端渲染引擎。这个引擎要自带组件模型、声明式视图和虚拟 DOM diff相当于一个简化版的框架核心。目标是把“声明式 UI 是怎么跑到真实页面上的”这件事彻底弄明白。1.2 定义边界哪些功能必须有哪些坚决砍掉有了方向后我给 rea 划了一条很清楚的边界线必须有JSX 语法支持一个完整组件树组件状态和全局状态的管理能力一套可视为“渲染到真实 DOM 之前中间层”的虚拟节点结构当状态变化时能精准更新对应的真实 DOM而不是全页面重建在渲染任务较重时能主动让位给用户交互坚决不做不做服务端渲染不做路由不做样式隔离不做完整的依赖收集/响应式系统有些功能看起来很有诱惑力比如响应式系统听起来“很高级”但每加一个学习成本就指数上升。这个边界让我能在一个相对短的时间内走完“从编译到渲染再到更新”的闭环而不是把时间耗在旁支功能上。1.3 为什么边界比功能更重要很多小型项目夭折不是因为功能不够而是因为什么都想做。把 rea 定为一个“以学习为目标的最小引擎”之后所有技术决策都有了判断标准。比如有人可能想上 TypeScript但为了减少一层编译复杂度我在第一版用了纯 JavaScript 的 JSDoc 标注比如有人可能想直接上 vite但为了看清楚 JSX 翻译过程我保留了手动编译这一步。边界一旦清晰纠结自然就消失了。这个阶段我学到的东西其实跟写代码没有关系纯粹是关于“如何管理自己的贪心”。2. 为什么不直接引入框架偏要自己造一个简化版2.1 套框架时你失去的东西我自己是每天都在用成熟框架的人并不反对框架。但如果你想把“状态变化如何变成页面变化”讲清楚框架的封装反而成了障碍。框架帮你把脏活干好但也把关键路径藏起来了。直接看框架源码也是一条路但成熟框架动辄几十万行里面包含了运行时兼容、不同平台适配、性能优化黑魔法新手很难分清哪些是核心原理、哪些是工程妥协。自己从零写一个 rea 类似物等于是把核心路径亲自走一遍复杂度完全由自己控制。2.2 rea 的路线选择下表是我在动手前做的技术路线对比候选方案优点缺点我的选择直接使用成熟框架稳定、文档全、生态好原理隐藏在抽象层学习成本高否学习项目不需要阅读源码加笔记成本低能接触真实实现容易被细节淹没难以体系化否缺少动手验证自研轻量渲染引擎完全可控能验证每个假设需要投入时间有踩坑风险是这张表可能看起来像废话但真正重要的是最后一行背后的心理建设我会反复跟自己说这不是重复造轮子而是为了验证一个假设——“一个只有完整框架三分之一复杂度的引擎能不能覆盖绝大多数声明式 UI 场景”。如果能说明框架里很大一部分复杂度是为极端场景准备的这对我们日常做技术选型是有参考价值的。毕竟你平时在项目里决定“要不要引入这个大库”本质也是在做类似的取舍。2.3 rea 最终确定的架构组成rea 的代码结构只有四块createElement负责把 JSX 编译产物转换成普通对象。render负责从虚拟节点生成真实 DOM并挂载到容器。reconcile负责比较新旧虚拟节点找出差异并执行真实 DOM 的最小修改。scheduler负责把渲染任务拆分成小块避免长时间阻塞浏览器主线程。四块加起来第一版核心代码只有一千行出头。这个行数说明一个问题框架的“核心思想”其实不复杂复杂的是各种边界条件和配套生态。比如错误处理、服务端渲染、并发特性、设备兼容这些都会把代码量迅速推高。所以不要被“框架源码那么庞大”吓到你只需要抓住骨架其余的都是肉。3. 渲染链路我是怎么把 JSX 变成真实 DOM 的3.1 JSX 编译后到底是什么如果你没用过 Babel 的插件可能不知道 JSX 不会直接进浏览器。它会被编译成 createElement 的函数调用。比如const vnode div classNameboxhello rea/div编译后会变成const vnode createElement(div, { className: box }, hello rea)每个 JSX 节点本质上就是一个配置对象。要写一个前端渲染引擎第一步就是把 createElement 做成一个“只返回普通对象、绝不直接操作 DOM”的纯函数function createElement(type, props, ...children) { return { type, props: props || {}, children: children } }很多人会不理解为什么要绕这么一层直接 document.createElement 不是更快吗因为虚拟节点是“未来状态的描述”它不持有真实 DOM 的引用所以可以随时重建、随时丢弃。只有到了 commit 阶段才把最新描述翻译成真实 DOM 操作。这个分离是所有声明式 UI 的地基。3.2 虚拟节点的形状除了 type 和 children 还需要什么随着项目推进我发现自己还需要给节点加两个“元信息”字段。第一个是 key用于在列表更新时识别“哪个节点对应哪个数据”。第二个是 index用于在同层对比时减少查找时间。这其实是完整框架里的 fiber 结构的一个极简版真正框架里每个节点还串联了 alternate、return、sibling 等等我全部砍掉了只保留当前节点需要的字段。砍掉之后diff 算法从“树上递归”变成了“同层数组扫描”复杂度简化非常多但代价是跨层级的节点移动不会做最优复用。这个问题我一开始很纠结后来发现绝大多数业务更新都是同层的跨层移动节点的场景很少见就算见了性能损失也就是一次节点重建不会带来逻辑错误。3.3 diff 的三个规则我的 diff 只做三件事每条规则背后都有明确理由类型不同直接替换整个节点。因为不同类型意味着结构和状态完全不同保留 node 没有意义。比如一个 div 变成了 button你总不能硬把 div 的属性挪过去。同类型复用真实 DOM 并更新属性和 children。注意是“复用”而不是“重建”这是 diff 能省性能的核心。真实 DOM 创建和插入是最贵的操作复用能省下大头。列表更新时先用 key 找到旧节点对应的位置找不到就当新增处理。这套规则是完整框架 diff 的书面总结。如果你去读成熟框架的源码会发现 diff 会复杂得多确实如此但 rea 的逻辑控制在三句话之内反而容易验证。实现时唯一要小心的就是“更新属性”的方法因为 className、style、事件监听器这三类的处理方式完全不同。我自己写了一个 setProps 函数每次进入都先清掉旧事件再挂新事件虽然代价是事件绑定会比原生频繁但换来的是不会出现幽灵监听器问题。这个取舍在两三万个节点上才会有点性能影响普通页面完全无感。4. 调度器让渲染像我欠了用户债一样排队执行4.1 为什么一个“只有一千行”的引擎也需要调度器当列表有几千个节点时一次状态更新如果被同步执行整棵树的 diff 和 DOM 操作会占据浏览器主线程很久用户会感觉到输入延迟或者动画卡顿。调度器的核心职责就是把原本一次性做完的大任务拆成多个小块在浏览器空闲时间做。这跟搬货很像——你不会一侧身就把所有货全搬到楼下你会一次搬几箱搬完一箱看看电梯门有没有要关的意思。浏览器给我们的工具是 requestIdleCallback它会等当前帧的空闲时间到了才回调。rea 的调度器在第二版才加上第一版打开一个一万节点的列表输入框敲一个字能卡接近一秒加上调度器之后卡顿基本消失。这个体验对比远比任何性能测试数据都有说服力。我当时的感受是自己实现了之后才真正理解为什么主流框架要把调度器做成核心能力因为它直接决定了应用在复杂页面上的“手感”。4.2 调度器的最小实现我实现了一个约 60 行的任务队列let tasks [] let isScheduled false function schedule(task) { tasks.push(task) if (isScheduled) return isScheduled true requestIdleCallback(flush) } function flush(deadline) { while (tasks.length 0 deadline.timeRemaining() 1) { const task tasks.shift() task() } isScheduled false if (tasks.length 0) { schedule(() {}) } }这个实现有个关键缺陷requestIdleCallback 在部分环境下可能一直不触发导致任务被无限拖延。我后来加了一个兜底如果三帧约 50ms内没有空闲回调就直接用 setTimeout 强制执行剩余任务。优先级降级逻辑也是在同样位置加的输入相关的更新可以排队等待但不能被饿死。这里我没有用 requestAnimationFrame 做调度因为它偏向动画时间线而渲染任务需要的是“空闲时间”两者目标不一样混用反而容易出问题。4.3 级联更新和优先级调度器带来的隐藏收益给 rea 加了调度器之后我顺手实现了两个之前一直不敢碰的功能。第一个是级联更新——一个组件状态变化导致另一个组件状态变化在同步模型里可能引发渲染递归在调度模型里变成了普通任务入队天然避免了栈溢出。第二个是让“高优先级任务插队”比如输入框的更新永远排在列表重排前面。这个能力在第一版纯同步渲染里几乎不可能优雅实现但在队列模型里就是多一个 sort 或者 unshift。所以我的感受是调度器不是性能加分项而是一个引擎从玩具走向可用的分水岭。没有调度器引擎只能在“小页面”上自娱自乐有了调度器才敢把它放到真实数据量的场景里。5. 状态管理订阅、批量更新和闭包陷阱5.1 状态应该挂在哪一层刚开始我直接把状态放在每个组件内部后来发现全局状态比如用户信息、主题色在跨组件共享时非常痛苦。rea 最后采用的结构是组件局部状态挂在组件自己的闭包里全局状态放在一个独立的 store 对象里任何组件都可以通过 subscribe 订阅 store 的变化。这种模型简单到没什么值得炫耀但它让我更理解一件事状态管理的第一要务不是“让更新更快”而是“让更新的路径可预测”。只要路径可预测问题就好排查。如果你把状态这里放一点、那里存一份最后连“这个值是从哪来的”都说不清楚那再快的状态库也救不了你。5.2 批量更新的实现如果用户在事件处理函数里连续调用几次 setState每次都触发渲染会造成大量重复 diff。rea 的做法是把 setState 的触发逻辑改成异步刷新状态先合并到一个队列中等当前同步代码执行完再一次性进入渲染阶段。let batchQueue [] let isFlushing false function setState(patch) { batchQueue.push(patch) if (isFlushing) return isFlushing true Promise.resolve().then(() { Object.assign(store, ...batchQueue) batchQueue [] isFlushing false renderApp() }) }这看起来简单但里面有个容易被忽略的点如果你在事件处理函数里依赖于 setState 之后的 store 值读取读到的是旧值因为它要等微任务才合并。很多人会在这里踩坑。解决方案是 setState 直接返回合并后的快照或者提供 getState() 供你在同一个微任务里读最新值。rea 选择了后者因为 getState 是一个显式动作更符合直觉。批量更新这个设计我也不是一开始就明白是写完同步渲染后自己在控制台实验连续三次 setState 时发现页面被渲染了三遍才回头加上去的。5.3 闭包陷阱我的一个真实翻车现场我在写一个倒计时组件的时候用了这样的代码function useCountdown(seconds) { const [count, setCount] createState(seconds) useEffect(() { const timer setInterval(() { setCount(count - 1) }, 1000) }, []) return count }这个count是 effect 创建时的值永远等于初始 seconds。因此 setCount 每次都在设置同一个值倒计时纹丝不动。这个 bug 我排查了很久因为控制台打印的 count 看起来每次都不同——其实打印的是组件重新渲染时的值而不是 effect 闭包里的值。解决方式是 setCount 支持函数式更新setCount(prev prev - 1)。这个经历让我明白闭包陷阱不是某个框架独有的而是所有用闭包保存状态的方案都会遇到的问题。rea 的第二版开始我强制自己写任何异步更新都用函数式写法这才把这类 bug 从根上踢掉。6. 测试结果、那些反直觉的发现和给后来者的建议6.1 与原生 DOM 操作和全量重建的对比我在本机用一个 5000 行表格做了一组对比测试结果如下更新场景全量重建删掉全部再插入rea diff 更新原生手动 DOM 更新修改 1 个单元格71ms4ms1ms修改 100 个单元格75ms12ms9ms表格行排序82ms18ms无法直观估测结果里有两点出乎我的意料。第一修改 1 个单元格时rea 的 diff 比原生慢因为要遍历整个虚拟 DOM 树找差异原生是直接定位。第二行排序这种场景rea 的胜出非常夸张原因是全量重建把 DOM 从无到有再造了五千次而 diff 只做了几十个节点的移动和更新。这说明 diff 的价值不在“每一次操作都更快”而在于“无论业务逻辑多复杂更新代价都维持在一个低且稳定的量级”。这个稳定性正是声明式 UI 最大的工程价值。6.2 三个反直觉的实测结论第一小列表少于 200 个节点直接重建比 diff 更快。diff 的前置遍历成本虽然不高但仍然存在。所以我给 rea 加了一个阈值节点总数小于阈值时直接跳过 diff走全量重绘。第二key 如果写错性能可能比不写更差。不写 key 时引擎用 index 做标识状态错乱是隐性摸不到的写了错误 key引擎会在 diff 环节多做大量无效匹配性能下降非常明显。这也是我在真实项目中最容易看到的问题。第三调度器在低端设备上反而容易让渲染看起来变“慢”因为任务被拆碎后中间状态会闪现。rea 的处理是只对“耗时超过 16ms 的大任务”启用时间切片小任务还是同步执行既不阻塞也不会闪烁。6.3 给想复刻 rea 的人的一些建议如果看完你也想自己写一个类似的迷你渲染引擎我的建议有三条。第一第一版千万不要加调度器先把同步渲染跑通感受一下它有多卡再回头加调度你会对必要性有最真实的体感。第二所有状态更新都必须走统一入口不要在业务代码里直接操作 DOM否则后期排查成本会高到你怀疑人生。第三写测试时优先覆盖三类用例列表增删、组件卸载时的事件清理、以及 effect 里异步更新。这三类用例基本能覆盖我踩过的全部坑。我在 rea 这个模拟项目里的定位始终是“学习验证器”而不是“生产替代品”如果你想要的是生产级的完美框架那直接看成熟框架源码会是更高效的路。最后说点个人的体会。rea 这个项目最大的收获不是那一千行能跑的代码而是让我在写每一块功能之前都学会了先问一句“这东西要是没有的话会发生什么”。很多模块听起来是必备的比如调度器、函数式更新实际上没有它系统也能跑只是会在特定场景暴露出问题。真正核心的往往是那几条最朴素、最容易被忽略的链路。到现在我还在给 rea 加新东西比如高阶组件和错误边界每次加之前还是会用同样的问题先问自己一遍。如果你手头也有一个这样模模糊糊的代号不妨也一样别急着写功能先把边界和动机想清楚后面会顺很多。