React 為什麼能撐住大型前端：我看見的是「組合」帶來的可維護性

我以前也把 React 當成「把 UI 拆成元件」的工具而已。真正讓我改觀的，是當專案開始變大：人變多、功能變多、需求變動變快，你會發現 React 的強項不是某個 API，而是一整套「用組合管理複雜度」的思考方式。

它把 UI 的複雜度，拆成兩種你可以分開處理的東西：

這種拆法在小專案看不出差異，但在大型專案，會直接影響你能不能活下來。

React 一開始就把重點放在「宣告式 UI」：你描述在某個 state 下畫面應該長什麼樣，React 去負責把它更新到正確狀態。這件事看似理所當然，但它帶來的架構好處是：

這會讓大型專案更像在維護一個「狀態機的投影」，而不是一堆互相踩腳的事件處理器。

我最常在 code review 看到的分歧是：有人想做「通用大元件」，有人想做「一堆小元件」。React 的路線其實很明確：你要把可重用性建立在組合上，而不是繼承或魔法參數上。

在大型架構裡，我會用三種組合方式來穩定專案：

好處是：資料來源換掉、快取策略換掉、API 形狀調整，都不會一路污染到 UI 細節。

需求最愛改的是「這裡多一段、那裡少一段、這個流程多一步」。與其一直加 boolean props，我更偏好把可變的區塊交給組合：

這種架構很像積木：需求變動時你換積木，不是去改積木裡面的齒輪。

當一個 state 影響多個區塊，就把它提升到共同祖先；當它只影響局部，就留在局部。這看起來很基本，但它其實是在做一件事：把一致性成本集中管理。

React 的下一個大型架構方向，我認為不是「又多一個 hook」，而是讓你更清楚地切割：哪些東西應該留在 client，哪些東西其實更適合在 server 先完成。

React Server Components（RSC）的價值在我眼裡很務實：它讓你可以把「拿資料、組 UI」這件事更靠近資料層完成，並把不需要互動的部分不用送到瀏覽器。你用 "use client" 把互動留在客戶端，其它可以留在 server。

但我也會提醒：這不只是效能議題，也是依賴治理議題。當架構開始吃到更多 server-side runtime 與打包鏈，升級策略會變成架構的一部分。

在大型專案最浪費時間的效能問題，常常不是「真的慢」，而是「大家害怕它會慢」，於是到處塞 useMemo / memo / useCallback，最後變成可讀性下降、bug 變多、而且效益不一定存在。

React Compiler 的方向我很喜歡：它把一部分「自動 memoization」交給工具，讓團隊回到更健康的默認值：先寫清楚，再針對真正瓶頸處理。

如果你正在做一個會長大的產品，我會用這幾條把 React 的優勢變成工程策略：

React 不是保證你永遠不痛，但它提供了一個很好的預設：讓你的程式碼在變大之後，仍然可以用「拆分、組合、替換」來演進，而不是用「硬改、硬撐、硬救火」來維持。