React把4个函数藏了10年，开发者自己写了一遍才懵

2013年React开源时，没人想到这个库的"心脏"只有4个函数。10年后，仍有开发者花3小时写了一遍，才发现自己用了8年的框架，底层竟如此朴素。

这4个函数是：h、render、diff、patch。它们构成了虚拟DOM（Virtual DOM）的完整生命周期——创建节点、挂载到真实DOM、对比差异、应用最小变更。没有类、没有事件总线、没有响应式系统。100行原生JavaScript，零依赖，浏览器直接运行。

为什么虚拟DOM不是性能优化

Svelte作者Rich Harris在2018年提出过一个反直觉观点：虚拟DOM不会让DOM操作更快，反而增加了一层计算开销。这句话至今成立。

虚拟DOM的真正价值是编程模型。你描述UI应该长什么样，框架算出最小变更路径。不用手动操作DOM节点，不用追踪状态变化的具体影响范围。这种"声明式"写法降低了心智负担，代价是多一次内存中的树形对比。

React团队从未隐瞒这一点。但大多数开发者停留在"虚拟DOM快"的模糊认知，直到性能分析工具里出现看不懂的火焰图，或者遇到 reconciliation（协调算法）相关的诡异bug，才意识到模型里有黑洞。

自己实现一遍，是填补黑洞最快的方式。

4个函数的极简实现

先看最终API设计——这是写代码前的"骨架"：

// 创建虚拟节点 const vdom1 = h('div', { id: 'app' }, h('p', {}, 'Count: 0') );

// 挂载到真实DOM const container = render(vdom1); document.body.appendChild(container);

// 状态变化后，生成新树 const vdom2 = h('div', { id: 'app' }, h('p', {}, 'Count: 1') );

// 计算差异 const patches = diff(vdom1, vdom2);

// 只应用变更 patch(container, patches); // 结果：只有文本节点从"0"变成"1"，div和p完全不动

h函数返回一个纯JavaScript对象，没有原型链污染，没有框架魔法：

const vnode = { type: 'p', props: {}, children: [{ type: 'TEXT_NODE', props: { nodeValue: 'Count: 0' } }] };

这个结构完全镜像DOM树，但活在内存里。真实DOM对它一无所知，直到render()遍历树并创建实际元素。

render：从描述到实体

render函数的工作是"物化"——把内存中的描述变成浏览器能画的节点。递归遍历vnode树，遇到元素类型就createElement，遇到文本类型就createTextNode，props变成setAttribute调用。

这一步没有 diff 的聪明，只有机械的创建。但它是整个系统的锚点：虚拟DOM再抽象，最终必须落地到真实DOM才能被用户看见。

diff：两棵树的对比游戏

diff是核心算法，也是React源码中最难啃的部分。但最小实现可以极度简化：只比较同层节点，类型不同直接替换，类型相同对比props和children。

这种"暴力"策略在真实React中被优化——key属性帮助识别移动节点，启发式算法假设用户不会疯狂重排列表。但100行版本不需要这些，它证明一个观点：即使最朴素的diff，也能让声明式UI跑起来。

diff的输出是一组"补丁"（patches），描述要对真实DOM做什么：替换节点、删除子树、更新文本、修改属性。patch函数按顺序执行这些操作，完成UI更新。

写完之后，React变轻了

完成这100行代码的开发者，反馈出奇一致：React的文档突然好懂了。之前模糊的"协调""批量更新""时间切片"，现在有了具体的锚点——它们是对这4个函数的工程优化，而非黑魔法。

有个细节值得玩味：React 18的并发特性（Concurrent Features）本质上是在render和patch之间插入"可中断"的调度点。理解基础实现后，高级特性的设计动机变得透明——不是炫技，是在保活编程模型的前提下，解决长任务阻塞主线程的问题。

10年前，React用这4个函数说服了前端社区：声明式UI值得追求。10年后，你自己写一遍，会重新评估这个承诺的分量——它确实降低了日常开发的心智负担，但也把复杂性转移到了框架内部，转移到了那些你曾以为是"性能优化"的抽象层。