截至目前(2026/03) Next.js 最新且最受歡迎的技術，莫過於這個 App Router與他帶來的RSC架構與Server Actions API了，不僅提供了全新的渲染模式，還大幅度的提升了DX。
今天就來介紹一下RSC是什麼? Server Actions又是什麼? 可以吃嗎?

要了解RSC是什麼，就要先了解 "為什麼需要RSC?"，這裡就要講到Next.js 的兩種路由了:

Pages Router

早期(2016~2023)的Next.js是用Page router進行渲染的，他是一種基於Client-side React的機制，它的核心邏輯很簡單：一個檔案就是一個路由（例如 pages/about.tsx 就是 /about 頁面）。

這個架構的最大的好處就是他 "非常淺顯易懂"，對初學者來說，他只要知道: 我要寫一個頁面，就新增一個檔案。可是當今天網頁越做越複雜(一堆動畫、3D渲染)時，他的缺點就出現了 - Hydration (對DOM event 下載並執行 JavaScript)

在 Pages Router 裡，一個頁面通常被打包成一個巨大的 JavaScript 檔案（Bundle）。因為 React 組件在 Pages Router 中是整塊運行的，編譯器很難精準地把「靜態 HTML」跟「JS 邏輯」拆開。

這就導致即便你的頁面 90% 都是靜態文字，只要有 10% 是互動按鈕，瀏覽器還是得下載、解析並執行整個頁面的 JavaScript。這會導致 LCP (最大內容繪製) 和 TBT (總阻塞時間) 指標變差。

於是聰明的Next.js 工程師決定發起一個革命性的更新: 重新制定路由規則 !

App Router

Client & Server Components

在頁面渲染方面，App Router提供了"Client & Server Components"，也就是RSC ( React Server Components)架構。這種架構允許開發者在頁面的最上方以 use client 或 use server "自定義"自己的組件想要在哪裡執行(預設use server )。

根據官方的建議:

Use Client Components when you need:

• State and event handlers. E.g. onClick, onChange.
• Lifecycle logic. E.g. useEffect.
• Browser-only APIs. E.g. localStorage, window, Navigator.geolocation, etc.
• Custom hooks.
  Use Server Components when you need:
• Fetch data from databases or APIs close to the source.
• Use API keys, tokens, and other secrets without exposing them to the client.
• Reduce the amount of JavaScript sent to the browser.
• Improve the First Contentful Paint (FCP), and stream content progressively to the client.

簡單來說，Server Components其代碼等，只會留在伺服器。使得傳送到瀏覽器的 JavaScript 體積大幅減少。對於內容導向的網站（如部落格、產品頁），使用者下載的 JS 可能減少 70% 以上，直接優化了 LCP（最大內容繪製）速度。

Server Actions

而API的處理上，App Router也提供了更簡便的方式: Server Actions

它允許我們透過JS(或TS)將後端寫成一個Funciton，之後要用到時只需要await Function()就好。這對於習慣用JAVA Spring Boot 寫後端的我來說實在是真的很震驚! (有寫過Spring Boot 的應該都知道寫個GET也要設定一大堆檔案)

在實務中我們會在Page.tsx(父層)寫GET的邏輯 (靜態邏輯)，在Components.tsx(子層)中寫Update, Delete, Create (互動性邏輯)。而use client寫在子層。

傳統方式 (2 次往返)：

瀏覽器 -> 伺服器：執行 Update。
伺服器 -> 瀏覽器：回傳成功。
瀏覽器-> 伺服器：再次發起 GET 或 refresh 請求來拿新資料。

Server Actions (1 次往返)：

在 Server Action 函數最後寫上 revalidatePath('/')。當你執行這個 Action 時，Next.js 會在同一個伺服器請求週期內：
執行資料庫更新。
重新渲染受影響的 Server Components (父層的 Page.tsx)。
將「更新後的資料結構 (RSC Payload)」與「Action 結果」一次性回傳給瀏覽器。

以mount舉例: Page router是伺服器給瀏覽器JS，瀏覽器解析完後遇到了GET，向伺服器發送GET請求，成功了再送回給瀏覽器。而App router是直接在伺服器渲染完(包含GET完)再一次給瀏覽器。

總結

App Router帶來的RSC與Server Actions 雖然帶來了革命性的改變，但缺點也顯而易見: 對初學者來說實在不好理解，雖然App Router還是有缺點(如Server負擔太大)但最大的問題真的就是"太難了"，其實 App Router還牽扯到很多快取機制的問題和渲染的流程，也更接近Client-Server的運作原理機制。這些就之後有緣再說了~ 今天先說到這!