2013年React開源時(shí)，沒(méi)人想到這個(gè)庫(kù)的"心臟"只有4個(gè)函數(shù)。10年后，仍有開發(fā)者花3小時(shí)寫了一遍，才發(fā)現(xiàn)自己用了8年的框架，底層竟如此樸素。

這4個(gè)函數(shù)是：h、render、diff、patch。它們構(gòu)成了虛擬DOM（Virtual DOM）的完整生命周期——?jiǎng)?chuàng)建節(jié)點(diǎn)、掛載到真實(shí)DOM、對(duì)比差異、應(yīng)用最小變更。沒(méi)有類、沒(méi)有事件總線、沒(méi)有響應(yīng)式系統(tǒng)。100行原生JavaScript，零依賴，瀏覽器直接運(yùn)行。

為什么虛擬DOM不是性能優(yōu)化

Svelte作者Rich Harris在2018年提出過(guò)一個(gè)反直覺觀點(diǎn)：虛擬DOM不會(huì)讓DOM操作更快，反而增加了一層計(jì)算開銷。這句話至今成立。

虛擬DOM的真正價(jià)值是編程模型。你描述UI應(yīng)該長(zhǎng)什么樣，框架算出最小變更路徑。不用手動(dòng)操作DOM節(jié)點(diǎn)，不用追蹤狀態(tài)變化的具體影響范圍。這種"聲明式"寫法降低了心智負(fù)擔(dān)，代價(jià)是多一次內(nèi)存中的樹形對(duì)比。

React團(tuán)隊(duì)從未隱瞞這一點(diǎn)。但大多數(shù)開發(fā)者停留在"虛擬DOM快"的模糊認(rèn)知，直到性能分析工具里出現(xiàn)看不懂的火焰圖，或者遇到 reconciliation（協(xié)調(diào)算法）相關(guān)的詭異bug，才意識(shí)到模型里有黑洞。

自己實(shí)現(xiàn)一遍，是填補(bǔ)黑洞最快的方式。

4個(gè)函數(shù)的極簡(jiǎn)實(shí)現(xiàn)

先看最終API設(shè)計(jì)——這是寫代碼前的"骨架"：

// 創(chuàng)建虛擬節(jié)點(diǎn) const vdom1 = h('div', { id: 'app' }, h('p', {}, 'Count: 0') );

// 掛載到真實(shí)DOM const container = render(vdom1); document.body.appendChild(container);

// 狀態(tài)變化后，生成新樹 const vdom2 = h('div', { id: 'app' }, h('p', {}, 'Count: 1') );

// 計(jì)算差異 const patches = diff(vdom1, vdom2);

// 只應(yīng)用變更 patch(container, patches); // 結(jié)果：只有文本節(jié)點(diǎn)從"0"變成"1"，div和p完全不動(dòng)

h函數(shù)返回一個(gè)純JavaScript對(duì)象，沒(méi)有原型鏈污染，沒(méi)有框架魔法：

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

這個(gè)結(jié)構(gòu)完全鏡像DOM樹，但活在內(nèi)存里。真實(shí)DOM對(duì)它一無(wú)所知，直到render()遍歷樹并創(chuàng)建實(shí)際元素。

render：從描述到實(shí)體

render函數(shù)的工作是"物化"——把內(nèi)存中的描述變成瀏覽器能畫的節(jié)點(diǎn)。遞歸遍歷vnode樹，遇到元素類型就createElement，遇到文本類型就createTextNode，props變成setAttribute調(diào)用。

這一步?jīng)]有 diff 的聰明，只有機(jī)械的創(chuàng)建。但它是整個(gè)系統(tǒng)的錨點(diǎn)：虛擬DOM再抽象，最終必須落地到真實(shí)DOM才能被用戶看見。

diff：兩棵樹的對(duì)比游戲

diff是核心算法，也是React源碼中最難啃的部分。但最小實(shí)現(xiàn)可以極度簡(jiǎn)化：只比較同層節(jié)點(diǎn)，類型不同直接替換，類型相同對(duì)比props和children。

這種"暴力"策略在真實(shí)React中被優(yōu)化——key屬性幫助識(shí)別移動(dòng)節(jié)點(diǎn)，啟發(fā)式算法假設(shè)用戶不會(huì)瘋狂重排列表。但100行版本不需要這些，它證明一個(gè)觀點(diǎn)：即使最樸素的diff，也能讓聲明式UI跑起來(lái)。

diff的輸出是一組"補(bǔ)丁"（patches），描述要對(duì)真實(shí)DOM做什么：替換節(jié)點(diǎn)、刪除子樹、更新文本、修改屬性。patch函數(shù)按順序執(zhí)行這些操作，完成UI更新。

寫完之后，React變輕了

完成這100行代碼的開發(fā)者，反饋出奇一致：React的文檔突然好懂了。之前模糊的"協(xié)調(diào)""批量更新""時(shí)間切片"，現(xiàn)在有了具體的錨點(diǎn)——它們是對(duì)這4個(gè)函數(shù)的工程優(yōu)化，而非黑魔法。

有個(gè)細(xì)節(jié)值得玩味：React 18的并發(fā)特性（Concurrent Features）本質(zhì)上是在render和patch之間插入"可中斷"的調(diào)度點(diǎn)。理解基礎(chǔ)實(shí)現(xiàn)后，高級(jí)特性的設(shè)計(jì)動(dòng)機(jī)變得透明——不是炫技，是在?；罹幊棠Ｐ偷那疤嵯拢鉀Q長(zhǎng)任務(wù)阻塞主線程的問(wèn)題。

10年前，React用這4個(gè)函數(shù)說(shuō)服了前端社區(qū)：聲明式UI值得追求。10年后，你自己寫一遍，會(huì)重新評(píng)估這個(gè)承諾的分量——它確實(shí)降低了日常開發(fā)的心智負(fù)擔(dān)，但也把復(fù)雜性轉(zhuǎn)移到了框架內(nèi)部，轉(zhuǎn)移到了那些你曾以為是"性能優(yōu)化"的抽象層。