RSC 不是銀彈，是新的架構債

React Server Components（RSC）並沒有讓前端變簡單，它只是把複雜度搬到了你看不到的地方。

過去兩年 RSC 從實驗性功能變成 Next.js App Router 的預設模式，社群討論熱度居高不下。但在實務專案中，越來越多團隊開始反思一件事：當你只是要做一個後台、一個官網、一個中型電商前台，RSC 真的值得嗎？

RSC 到底解決了什麼問題

RSC 的核心價值很清楚：把資料抓取與部分渲染搬到伺服器端，讓 client bundle 變小、首屏更快、SEO 更穩。對於那些「內容極多、互動極少」的頁面——例如新聞、產品列表、文件站——這個取捨非常划算。

但 RSC 同時引入了一組新的心智負擔：

• Server Component 與 Client Component 的邊界必須手動劃分，"use client" 一旦放錯地方，整棵樹會默默變成 client-side render。
• 資料抓取從統一的 useQuery / SWR 模式，分裂成 server fetch、client fetch、Server Action 三種寫法。
• 快取行為（fetch 的 cache、revalidate、tags）變成一個獨立的學習曲線，debug 時你很難一眼看出某個請求為什麼被快取了。

換句話說，RSC 把一部分「執行時的效能問題」換成了「設計時的架構問題」。

// 示意：一個看似無害的 import 就讓邊界崩潰
// app/products/page.tsx (Server Component)
import { ProductCard } from './ProductCard'

export default async function Page() {
  const data = await fetch('...').then(r => r.json())
  return data.map((p) => <ProductCard key={p.id} {...p} />)
}

// ProductCard.tsx —— 因為用了 useState，整個元件變 client
'use client'
import { useState } from 'react'
export function ProductCard(props) { /* ... */ }

這段示意程式裡，只要 ProductCard 內部多了一個 onClick，整個產品列表就會被推到 client 端 hydrate。這類「無聲的退化」在 code review 時極難察覺。

什麼情境該用、什麼情境該躲

我們在報價或評估前端架構時，通常會用幾個問題快速過濾：

1. 這個專案的頁面，是內容導向還是互動導向？ 如果九成頁面是表單、儀表板、即時互動，SPA（Vite + React Query）通常更省事。
2. 團隊有沒有人熟悉 RSC 的快取模型？ 如果沒有，第一個 production bug 通常會花掉你預期之外的時間。
3. 後端 API 是不是已經穩定？ RSC 在「前後端同一個 repo、同一組人寫」時最發揮價值；如果你的後端是另一支團隊維護的 REST 或 gRPC 服務，那 server fetch 帶來的好處會大幅縮水。

舉個例子：假設一家傳產要做一個型錄網站，頁面以靜態內容為主、偶爾更新——這是 RSC（或更直接的 SSG）最甜蜜的場景。但如果今天要做的是一個內部 ERP 操作介面，全部都是表格、彈窗、即時編輯，那硬套 App Router 只會讓開發速度變慢。

我們的觀察

RSC 是一個值得學習的技術方向，但它不是「新的 React 就要用新的寫法」這麼單純。它代表的是一種架構選擇：你願意用更複雜的心智模型，換取更小的 client bundle 與更彈性的渲染策略。

對中小型專案、對需要快速交付的客製化系統，先把 SPA 寫好、把 API 設計好，往往比追逐最新範式更實際。技術趨勢值得追，但不必每一波都跳。