為什麼 React 和 Vue 不一樣？

依舊能記起當年 React 和 Vue 剛火時，前端之間一直有個爭論：使用 React 還是使用 Vue。當年這個議題吵得熱火朝天，當時就在想，為什麼這兩個框架會有這麼大的差異？造成這些差異的原因是什麼？為什麼兩個框架走的不同路徑，但是給開發者的體驗卻是相似的？種種問題都在我的腦海中迴盪，可惜當年還是一個初入門的小白，雖然有這些問題，但是還是沒有自己找到答案。最近橫向和縱向各個維度深度對比了這兩個框架，答案就呼之欲出了。挺好，似乎回到了入門的起點。

一、為什麼兩種架構走向了不同的道路

1.1 UI 的本質是什麼

要理解 React Fiber 和 Vue 響應式系統為何走向截然不同的架構路徑，我們必須回到一個更根本的問題：使用者介面的本質是什麼。React 團隊給出的答案是——UI 是狀態的函數（UI = f(state)）。這個看似簡單的等式蘊含著深刻的架構決策：如果 UI 只是狀態的純粹映射，那麼每次狀態變化時，整個 UI 都應該被重新計算，框架的職責是透過 diff 演算法來將實際的 DOM 操作最小化。React 的虛擬 DOM 和 Fiber 架構都是這一觀點的工程實作，它們假設狀態變化是不可預測的、細粒度的，因此需要一個通用的執行期排程系統來處理任意複雜度的更新。這種設計賦予了 React 極強的靈活性和表達能力，但也帶來了不可避免的執行期開銷——每一次更新都需要走過「渲染 -> 虛擬 DOM 樹建構 -> Diff -> Patch」的完整鏈路。

Vue 的創始人尤雨溪對這個問題給出了不同的回答。在他看來，UI 的本質是響應式資料與 DOM 之間的綁定關係。當開發者宣告了一個模板（Template），其中的每一個插值表達式（{{ }}）、每一個指令（v-bind、v-if、v-for）都是在建立資料到視圖的明確對應。Vue 的核心在於：這種對應關係在編譯時就可以被靜態分析出來。因此，Vue 選擇將大部分優化工作前置到編譯階段，透過編譯器生成帶有優化標記的渲染函式，讓執行期的更新工作變得精準而高效。Vue 3 的 Proxy 響應式系統進一步強化了這種理念——當資料變化時，框架精確知道哪些元件、哪些 DOM 節點需要更新，不需要進行全樹掃描。兩種框架的分歧從這一刻起就已經註定：React 押注執行期排程的通用性和靈活性，Vue 押注編譯時優化的精準性和效率。

1.2 兩條路徑的技術 DNA

React 的技術 DNA 可以追溯到底層系統程式設計的啟發。Fiber 架構的設計者 Andrew Clark 曾明確表示，Fiber 是對作業系統執行緒排程模型的借鏡。在作業系統中，行程排程器需要在多個任務之間分配 CPU 時間片，確保高優先級任務（如使用者輸入）能夠及時回應，同時不讓低優先級任務（如背景計算）餓死。React Fiber 將同樣的思想引入了 JavaScript 的單執行緒環境：透過將渲染工作拆分為可中斷的「工作單元」，並利用瀏覽器的 requestIdleCallback 機制，React 可以在每一幀的空閒時間內執行一小部分渲染工作，高優先級更新則可以隨時「搶佔」當前工作。這種架構賦予了 React 時間切片 和 並發渲染 的能力，使得 React 能夠在不阻塞主執行緒的前提下處理大規模元件樹的更新。

Vue 的技術 DNA 則源於 資料綁定 和 依賴追蹤。Vue 2 使用 Object.defineProperty 對資料物件進行遞迴攔截，在 getter 中收集依賴，在 setter 中觸發更新。Vue 3 則將這一機制升級為基於 ES6 Proxy 的響應式系統，搭配 Reflect API 實現更完整、更高效的攔截。Vue 的核心設計哲學是 讓框架自動追蹤資料與視圖之間的依賴關係，開發者無需手動宣告依賴（不像 React 的 useEffect 需要明確傳遞依賴陣列）。當 ref 或 reactive 物件的值發生變化時，Vue 的響應式系統能夠精確通知到依賴於該資料的每一個副作用（Effect），包括元件的重新渲染、computed 屬性的重新計算、watch 回呼的執行等。這種「自動追蹤、精確觸發」的機制，使得 Vue 在大多數場景下能夠實現 O(1) 的更新複雜度——即更新成本與受影響的節點數量成正比，而非與元件樹的總規模成正比。

1.3 核心差異一覽

二、React Fiber：在單執行緒世界裡的排程器

2.1 Stack Reconciler 的困局

在 React 16 之前的 Stack Reconciler 時代，React 的更新過程可以簡單概括為 「一梭到底」。當元件狀態發生變化時，React 會從根節點開始，遞迴遍歷整棵元件樹，計算新的虛擬 DOM 樹，與舊的樹進行 Diff，最後一次性將所有變更提交到真實 DOM。這個過程完全 同步 且 不可中斷——一旦開始，就必須等到全部完成才能將控制權交還給瀏覽器。對於小型應用，這種方式工作得很好，因為整個更新過程可能只需要幾毫秒。但隨著應用規模的增長，元件樹可能包含數千個節點，一次完整的 reconciliation 可能消耗數十甚至上百毫秒，直接阻塞瀏覽器的主執行緒。

這種阻塞帶來的使用者體驗問題是災難性的。我們想像一下，使用者在搜尋框中輸入文字，同時後台正在接收即時資料更新。在 Stack Reconciler 中，資料更新觸發的重渲染可能會完全占用主執行緒 100ms，在這段時間內，使用者的鍵盤輸入事件被掛在事件佇列中無法得到回應——使用者會感覺「卡頓」。更嚴重的是，動畫在這段期間完全停滯，因為瀏覽器沒有機會執行 requestAnimationFrame 回呼。React 團隊意識到，問題的根源不在於虛擬 DOM 本身，而在於 JavaScript 的執行模型——呼叫堆疊是後進先出的、不可搶佔的資料結構，一旦進入深層遞迴，就沒有優雅的方式來「暫停」當前工作去處理更緊急的任務。

2.2 Fiber 的創新：重新實作呼叫堆疊

React Fiber 的創新點在於它對這一底層問題的回應：如果瀏覽器的呼叫堆疊不夠靈活，那就自己實作一個。Fiber 架構的本質是一種 使用者空間排程器，它將原本由 JS 引擎管理的呼叫堆疊轉換為顯式維護的鏈結串列資料結構。每一個 React 元件實例不再只是一個函式呼叫，而是一個持久化的 Fiber 節點物件，其中包含了 child（第一個子節點）、sibling（下一個兄弟節點）和 return（父節點）三個指標，構成了一棵可任意遍歷、暫停和恢復的樹狀鏈結串列。

這種資料結構的選擇絕非偶然。鏈結串列結構使得 React 可以徹底放棄遞迴（recursion），改用迴圈（loop）來遍歷元件樹。在迴圈的每一次迭代中，React 處理一個 Fiber 節點，然後檢查當前幀的剩餘時間。如果剩餘時間不足（React 預設設定了一個約 5ms 的幀預算），或者檢測到有更高優先級的更新到來，React 可以立即保存當前的工作進度（記錄下一個待處理的 Fiber 節點引用），將控制權交還給瀏覽器，然後在下一幀的 requestIdleCallback 回呼中無縫恢復工作。Andrew Clark 將 Fiber 描述為 「一個專門用於 React 元件的虛擬堆疊框架」——它的核心優勢在於，這些堆疊框架存儲在堆積體記憶體中，React 可以完全控制它們的執行順序和時機，這是作業系統呼叫堆疊所不具備的能力。

2.3 雙緩衝架構與兩階段提交

Fiber 架構引入了 雙緩衝 的記憶體模型，這是另一個深刻影響 React 更新行為的創新。React 在記憶體中同時維護兩棵 Fiber 樹：一棵是 current 樹，代表了目前螢幕上真實 UI 的狀態；另一棵是 workInProgress 樹，用於進行正在進行的渲染計算。當更新觸發時，React 並不會直接修改 current 樹，而是基於它複製出一棵 workInProgress 樹，所有的 reconciliation 工作都在這棵「草稿」樹上進行。這個設計的精妙之處在於 渲染過程完全不會影響使用者看到的介面——即使渲染過程中途被中斷或完全丟棄，使用者看到的依然是 current 樹對應的一致 UI。

當 workInProgress 樹的所有工作完成後，React 進入 提交階段（Commit Phase）。這是一個 同步、不可中斷 的階段，React 將 workInProgress 樹的所有副作用（DOM 插入、更新、刪除，以及生命週期函式和 useEffect 回呼的排程）一次性應用到真實 DOM 上，然後原子性地將 workInProgress 樹切換為新的 current 樹。兩階段架構的嚴格分離是 React 並發特性的基石：渲染階段（Render Phase）可以被打斷和重啟，因為它只操作記憶體中的 workInProgress 樹；提交階段（Commit Phase）必須是原子的，因為此時正在修改使用者可見的介面，任何不一致都會導致視覺閃爍。

2.4 優先級排程與 Lane 模型

React 18 進一步演化出了 Lane 優先級模型，用 31 位元的二進位數來表示不同類型的更新優先級。每一位代表一個「通道」（Lane），不同的互動類型（使用者輸入、點擊、資料載入、過渡動畫等）被分配到不同的 Lane 上。React 可以精確判斷哪些更新更緊急，並支援 Lane 的「糾纏」（entanglement）機制——當高優先級更新和低優先級更新之間存在資料依賴時，React 會自動將它們合併渲染，防止出現視覺不一致。這種精細的優先級控制系統使得 React 能夠在極端複雜的並發場景中依然保持使用者互動的流暢性，但也顯著增加了框架的執行期複雜度和學習成本。

三、Vue 響應式系統：讓資料自己告訴你它變了

3.1 從 defineProperty 到 Proxy：響應式技術的演進

Vue 的響應式系統經歷了兩代重大演進。Vue 2 使用 Object.defineProperty 為物件的每一個屬性定義 getter 和 setter，在屬性被讀取時收集依賴，在被修改時觸發更新。這個方案在當時是創新的，但它有幾個根本性缺陷：首先，Object.defineProperty 只能攔截已經存在的屬性，無法偵測物件的新增加屬性和陣列索引的變化（這也是 Vue 2 需要 Vue.set 和 Vue.delete API 的原因）；其次，它需要對資料物件進行 深度遞迴遍歷，在初始化時就為每一層巢狀物件的每一個屬性都設定 getter/setter，這在處理大型資料物件時會產生大的效能開銷。

Vue 3 的響應式系統基於 ES6 的 Proxy 物件進行了徹底重寫。與 Object.defineProperty 不同，Proxy 可以攔截對目標物件的 任何操作——包括屬性讀取、賦值、刪除、列舉、函式呼叫、in 運算子，甚至 new 操作。這意味著 Vue 3 不再需要深度遞迴初始化：代理是「懶」的，只有當存取到某個巢狀物件時，才會遞迴地為該物件建立代理。更重要的是，Proxy 讓 Vue 3 天然支援 Map、Set、WeakMap、WeakSet 等 ES6 資料結構，以及陣列的所有操作（包括直接透過索引賦值和修改 length），無需任何特殊處理。

在 Vue 3 的原始碼中，reactive() 函式透過 new Proxy(target, mutableHandlers) 建立響應式物件，其中 mutableHandlers 包含了 get 和 set 攔截器。get 攔截器使用 Reflect.get(target, key, receiver) 讀取屬性值（Reflect API 的設計目的正是為了與 Proxy 搭配使用，提供更完整和規範的元程式設計能力），同時呼叫 track() 函式進行依賴收集；set 攔截器使用 Reflect.set() 寫入新值，然後呼叫 trigger() 函式通知所有依賴進行更新。這種 Proxy + Reflect 的組合已經成為現代 JavaScript 元程式設計的標準範式。

3.2 依賴收集的三劍客：TargetMap、Dep、Effect

Vue 3 的響應式系統內部維護了一個精巧的全域依賴追蹤結構。其核心是三個關鍵資料結構：

首先是 targetMap，一個 WeakMap<object, Map<string | symbol, Set<ReactiveEffect>>> 結構。它的作用是建立「響應式物件 -> 屬性鍵 -> 依賴集合」的三層對應。WeakMap 的選擇非常重要——它允許垃圾回收器在響應式物件不再被引用時自動回收其對應的依賴資訊，防止記憶體洩漏。當 track() 被呼叫時，Vue 會根據當前被存取的響應式物件和屬性鍵，找到或建立對應的依賴集合（Dep），然後將目前正在執行的 ReactiveEffect 實例加入這個集合中。

其次是 ReactiveEffect 類別，它是 Vue 響應式系統中「副作用」的抽象表示。元件的渲染函式、computed 屬性的計算函式、watch 的回呼函式，本質上都是 ReactiveEffect 的不同實例。每個 ReactiveEffect 有一個 run() 方法用於執行副作用，以及一個 deps 陣列用於記錄它依賴於哪些 Dep 集合。這種 雙向記錄 的機制——Effect 記錄它依賴了哪些 Dep，Dep 記錄哪些 Effect 依賴了它——是實現精確更新的關鍵。當響應式資料變化時，trigger() 函式只需要找到對應的 Dep 集合，遍歷其中的所有 Effect 並重新執行即可。

最後是排程器（Scheduler）。Vue 並不會在資料變化時立即同步執行所有副作用，而是將它們推入一個佇列，透過 nextTick 機制進行 非同步批次刷新。這意味著在同一個事件迴圈中發生的多個資料變化，只會觸發一次統一的 DOM 更新——這是 Vue 效能優化的重要手段。透過 Promise.then（或降級到 setImmediate / setTimeout），Vue 確保所有同步的資料變更都完成後，才在下一個微任務中執行副作用，這種批次處理策略大幅減少了不必要的重複渲染。

3.3 編譯器的智慧：從模板到優化標記

Vue 的響應式系統之所以高效，很大程度上歸功於其 編譯器的靜態分析能力。與 React 的 JSX 不同，Vue 使用基於 HTML 的模板語法。這種看似限制性的設計實際上為編譯器優化打開了巨大的空間。當 Vue 編譯器分析一個模板時，它能夠識別出哪些部分是 靜態的（不會隨資料變化），哪些是 動態的（綁定響應式資料）。

Vue 3 的編譯器引入了多項革命性的優化技術：靜態提升（Static Hoisting）將靜態節點從渲染函式中提取出來，只在首次渲染時建立一次，後續更新完全跳過這些節點；Patch Flags 為每一個動態節點打上一個優化標記，精確指示該節點的哪個部分可能變化（文字內容、類別名稱、樣式、屬性等），這樣執行期的 diff 演算法可以跳過完整的 props 比較，只檢查可能發生變化的特定部分；樹扁平化 打破了傳統的遞迴 diff 模式，將所有動態節點收集到一個扁平陣列中，diff 時只需要遍歷這個陣列而非整棵樹。這些編譯時優化的綜合效果，使得 Vue 3 的虛擬 DOM 更新效率遠超傳統的全樹 diff 實作——雖然 Vue 仍然使用虛擬 DOM，但它已經是一個被編譯器「武裝到牙齒」的高度優化版虛擬 DOM。

四、業界其他框架：百花齊放的方案

4.1 Svelte：編譯器即框架

如果說 React 代表了 「執行期最大化」 的極端，那麼 Svelte 則代表了 「編譯時最大化」 的另一個極端。Svelte 的創造者 Rich Harris 提出了一個激進的問題：如果框架在建置時就知道你的元件會如何變化，那為什麼還要在執行期做這些工作。Svelte 的核心架構決策是將框架本身「編譯掉」——最終執行在瀏覽器中的程式碼，幾乎是純粹的手寫 JavaScript DOM 操作，沒有虛擬 DOM，沒有響應式執行期函式庫，沒有 diff 演算法。

Svelte 5 進一步引入 Runes（如 $state、$derived、$effect），將響應式模型從隱式的編譯器魔法轉變為顯式的訊號（Signals）機制。編譯器分析元件模板中的每一個響應式綁定，生成精確的 DOM 更新程式碼。當 $state 的值變化時，編譯生成的程式碼直接呼叫 textNode.data = newValue 或 element.setAttribute('class', newClass)，沒有任何中間抽象層。這種架構的代價是 Svelte 需要一個功能強大的編譯器來處理各種邊界情況，但它的回報也是巨大的：Svelte 應用的執行期體積極其微小（約 2-3 KB gzip），更新效能接近原生 JavaScript，記憶體占用也遠低於虛擬 DOM 方案。

4.2 SolidJS：Signals 驅動的細粒度響應式

SolidJS 的創造者 Ryan Carniato 將「細粒度響應式」（Fine-grained Reactivity）推向了一個極致。Solid 同樣不使用虛擬 DOM，但它與 Svelte 的編譯器驅動方式有所不同：Solid 保留了 JSX 語法，其編譯器將 JSX 轉換為高效的 DOM 建立和更新指令，而響應式追蹤則在執行期透過 Signals 完成。Solid 的 createSignal 回傳一個 getter/setter 對，當在 JSX 或其他響應式上下文中讀取 signal 時，依賴關係被自動建立；當 signal 值變化時，只有直接依賴於該值的 DOM 節點會被更新。

SolidJS 的一個關鍵設計特點是 元件函式只執行一次。這與 React（元件函式在每次渲染時都重新執行）和 Vue（渲染函式在每次更新時重新執行）有著根本不同。在 Solid 中，元件的 setup 程式碼只在掛載時執行一次，後續所有的更新都透過訊號系統精確到達對應的 DOM 節點，無需重新執行元件函式。這種設計消除了「重新渲染」的概念，從根本上避免了虛擬 DOM 方案中因元件重渲染而產生的計算開銷。在 js-framework-benchmark 中，SolidJS 一直名列前茅，與原生 JavaScript 的效能差距極小，這驗證了細粒度響應式架構在效能上的巨大潛力。

4.3 Angular：從 Zone.js 到 Signals 的轉變

Angular 作為一個歷史悠久的企業級框架，其架構演進代表了另一個維度的思考。長期以來，Angular 依賴 Zone.js 進行變更偵測——Zone.js 透過猴子補丁（monkey-patching）瀏覽器的所有非同步 API（setTimeout、Promise、XHR、DOM 事件等），在任何非同步操作完成後自動觸發 Angular 的全域變更偵測。這種方案的優點是開發者完全不需要關心何時觸發更新——任何非同步操作後 Angular 都會自動檢查所有元件是否需要更新；缺點是效能極差，因為即使是最微小的狀態變化，也可能導致整個元件樹的髒檢查（Dirty Checking）。

Angular 16+ 開始引入 Signals（signal()、computed()、effect()），標誌著 Angular 正在從 Zone.js 的全域髒檢查模型向細粒度響應式模型遷移。Angular 的 Signals 設計與 SolidJS 類似，但提供了更漸進式的遷移路徑——開發者可以逐步將元件從 Zone.js 遷移到 Signals，而無需重寫整個應用。Angular 的轉變印證了一個業界趨勢：細粒度響應式正在成為前端框架的共識方向，即使是傳統上採用完全不同架構的框架也在向這一方向靠攏。

4.4 各框架架構對比

五、兩種框架什麼場景下使用（不一定對）

5.1 效能特性的場景化分析

React Fiber 的並發排程能力在大規模、高頻率、高並發更新的場景下展現出獨特優勢。比如一個複雜的股票交易儀表板：頁面上有數十個即時資料流（價格、成交量、委託深度），同時使用者正在與圖表互動（縮放、平移、選擇時間範圍）。React 的 Fiber 架構允許 使用者互動（高優先級）即時打斷資料更新（低優先級），確保圖表操作始終保持 60fps 的流暢度，而價格資料在後台以較低優先級逐步更新。如果沒有 Fiber 的排程能力，大量資料更新可能導致使用者互動出現明顯卡頓。React Compiler（原 React Forget）進一步透過編譯時自動插入 memoization 來減少不必要的重渲染，讓開發者不再需要手動管理 useMemo 和 useCallback。

Vue 的響應式系統在大多數常規應用場景下提供更優異的更新效率和開發體驗。由於 Vue 精確追蹤了每一個資料屬性與視圖之間的依賴關係，更新成本天然地與變更的影響範圍成正比，而非與元件樹的總規模成正比。這意味著在一個包含 1000 個元件的頁面中，如果只有底部一個計數器發生變化，Vue 只需要更新那個計數器對應的 DOM 節點，而 React（在沒有 Compiler 優化的情況下）可能需要重新渲染整個受影響的元件子樹，然後進行 diff。Vue 3.6 的 Vapor Mode 進一步將這一優勢推向極致：對於使用 Composition API 的元件，Vapor Mode 可以在編譯時直接生成 DOM 操作程式碼，完全跳過虛擬 DOM，實現與 SolidJS 媲美的效能。

5.2 開發者體驗：心智模型與學習曲線

React 的程式設計模型更接近 JavaScript 的函式式程式設計範式。Hooks（useState、useEffect、useMemo 等）的引入雖然解決了類別元件的邏輯重用問題，但也帶來了新的心智負擔：hooks 的呼叫順序必須嚴格一致（不能在條件語句中呼叫），依賴陣列需要手動維護（遺漏依賴會導致 bug），閉包陷阱（stale closure）是新手最常遇到的問題之一。React 的靈活性是一把雙刃劍——它允許你以幾乎任何方式組織程式碼，但也意味著團隊需要建立嚴格的程式碼規範來保持一致性。React Compiler 的出現正在緩解這些問題，透過編譯時自動優化取代了大部分手動 memoization 的工作。

Vue 的程式設計模型則更加 約定優於配置（Convention over Configuration）。模板語法（{{ }}、v-if、v-for、v-bind）對前端開發者來說非常直觀，因為它們本質上就是增強版的 HTML。Composition API 提供了與 React Hooks 類似的邏輯組合能力，但沒有了呼叫順序的限制，也沒有了依賴陣列——因為 Vue 的響應式系統 自動追蹤依賴，開發者不需要手動宣告。這種「自動依賴追蹤」的設計極大地減少了與響應式相關的 bug。對於初學者來說，Vue 的漸進式設計意味著可以從一個簡單的 script 標籤引入開始，逐步學習到完整的單檔元件（SFC）、Composition API、狀態管理（Pinia）和路由（Vue Router），每一步都有明確的指導路徑。

5.3 生態

React 的生態系統無疑是前端領域最為龐大和成熟的。從狀態管理（Redux、Zustand、Jotai、Recoil）到路由（React Router）、元框架（Next.js、Remix）、UI 元件庫（Material-UI、Ant Design、Chakra UI）、表單處理（React Hook Form、Formik）、資料獲取（TanStack Query、SWR），React 生態幾乎涵蓋了前端開發的每一個細分領域。Next.js 的 App Router 和 React Server Components（RSC）代表了 React 生態在伺服器端渲染和全端開發方向上的最新探索。對於大型企業和團隊來說，React 生態的廣度和深度意味著幾乎任何需求都能找到成熟的解決方案，招聘擁有 React 經驗的開發者也相對容易。

Vue 的生態系統雖然規模不及 React，但其 整合度更高、一致性更好。Vue 官方維護的核心生態庫（Vue Router、Pinia、Vite、VueUse、Nuxt.js）在 API 設計和發布節奏上保持高度統一，這大大降低了開發者在不同函式庫之間切換的認知成本。Nuxt.js 作為 Vue 的官方元框架，提供了開箱即用的伺服器端渲染、靜態生成、API 路由、自動匯入等全端功能，其開發者體驗在很多方面優於 Next.js。

六、融合的未來：架構趨同與各自進化

6.1 從對立到融合的產業趨勢

一個值得思考的現象是：React 和 Vue 雖然起源於完全不同的架構哲學，但是在最近的兩年裡，兩條技術路線正在呈現出 趨同。React 透過 React Compiler 在編譯時自動完成原本需要手動進行的 memoization 優化，實質上是在「借用」編譯時優化的思路來彌補虛擬 DOM 的效能缺陷；Vue 透過 Vapor Mode 探索無虛擬 DOM 的編譯策略，實質上是在向 Svelte/Solid 的細粒度響應式範式靠攏。兩者都在向對方擅長的領域延伸——React 增強編譯時能力，Vue 增強執行期排程能力。

這種趨同也不是偶然，而是前端架構演進的必然結果。無論是虛擬 DOM 還是細粒度響應式，最終目標都是「在狀態變化時高效地更新介面」。虛擬 DOM 的方案透過「通用執行期 diff」解決問題，優點是靈活性和可預測性，缺點是執行期開銷；細粒度響應式的方案透過「編譯時/執行期精確追蹤」解決問題，優點是極致的效能，缺點是更強的編譯依賴和對程式設計模式的約束。最優的架構必然是在兩者之間找到平衡點——利用編譯器做盡可能多的靜態分析和優化，同時保留執行期的排程能力來處理動態和不可預測的場景。

6.2 React 的未來：Compiler + Server Components

React 團隊正在全力推進三個方向的進化：React Compiler（建置時自動 memoization）、React Server Components（伺服器元件，零客戶端 bundle）、以及 Offscreen Rendering（離屏渲染，用於預載和保留元件狀態）。React Compiler 的成熟將從根本上改變 React 的效能優化範式——開發者不再需要手動撰寫 useMemo、useCallback 和 React.memo，編譯器會在建置時自動完成這些優化，且粒度通常比手動優化更細。React Server Components 則代表了 React 對「如何減少客戶端 JavaScript 體積」這一問題的回答：將純資料展示型元件放在伺服器端執行，只將互動型元件傳送到客戶端。這種伺服器優先的架構（Server-first Architecture）正在透過 Next.js 的 App Router 成為 React 生態的主流範式。

6.3 Vue 的未來：Vapor Mode + Alien Signals

Vue 的未來路線圖同樣清晰而且讓人期待。Vapor Mode 的目標是讓 Vue 在保持現有 API 不變的前提下，實現 SolidJS 級別的渲染效能——透過在編譯時生成直接 DOM 操作程式碼，完全跳過虛擬 DOM。這意味著 Vue 開發者無需改變任何程式設計習慣，只需開啟一個編譯器選項，就能獲得數倍的渲染效能提升。Vue 3.6 也在開發 Alien Signals——一套與框架無關的訊號系統實作，旨在讓 Vue 的響應式原語可以與其他訊號函式庫互操作。長期來看，Vue 的架構願景是成為一個可適應不同場景的靈活系統：對於簡單場景，Vapor Mode 提供極致效能；對於複雜場景，編譯器優化的虛擬 DOM 提供完整的特性支援；響應式系統作為獨立模組，可以與任何渲染層配合使用。

七、總結

React Fiber 和 Vue 響應式系統代表了前端架構設計中兩種取向。React 選擇了一條更接近電腦科學底層的路：重新設計呼叫堆疊，實作使用者空間排程器，以通用性和靈活性為代價，換來了對極端並發場景的掌控力。Vue 選擇了一條更接近應用開發本質的路：讓資料自己說話，讓編譯器做苦工，以更強的編譯時約束為代價，換來了大多數場景下的高效和優雅。

這兩種選擇沒有高下之分，它們是前端技術生態的 陰陽兩面——一方的創新會激發另一方的進化。Fiber 的並發排程啟發了 Vue 對非同步更新佇列的重構；Vue 的編譯器優化啟發了 React Compiler 的方向；Svelte 的編譯器範式啟發了 Vue Vapor Mode 的探索；SolidJS 的細粒度響應式啟發了 Angular Signals 的遷移。

這種跨框架的相互啟發和借鏡，恰恰說明前端架構的進化不是線性的，而是辯證的。每一個看似對立的技術選擇，實際上都在推動整個產業向前發展。React 的 Fiber 證明了在 JavaScript 單執行緒環境中實現複雜排程的可行性；Vue 的編譯器證明了靜態分析在現代 UI 框架中的巨大價值；Svelte 的編譯器範式證明了「沒有執行期」的可能性；SolidJS 的 Signals 證明了細粒度響應式的效能極限。這些探索共同構成了前端技術棧的知識積累，無論最終哪個框架占據主流，整個產業都從中受益。

原文出處：https://juejin.cn/post/7633774493807362048