一個常見的混淆
「我要做一個新專案，應該用 Next.js 還是 Express / NestJS？」
這個問題本身有個隱藏的前提問題沒有被問出來：你的系統是「前端應用需要 server 端支援」，還是「純後端 API service」？
這兩個的架構哲學是相反的，技術選型自然也不同。
Meta-framework 是什麼
Meta-framework（元框架）是在現有 UI library（React / Vue / Svelte）上面加一層 convention 的框架：
- Next.js：React 的 Meta-framework
- Nuxt：Vue 的 Meta-framework
- SvelteKit：Svelte 的 Meta-framework
- Remix：React，強調 web fundamentals（HTTP cache、form）
這些框架解的問題是：React / Vue 本身只是 UI library，沒有規定路由怎麼定義、資料怎麼取、static generation 怎麼做、server rendering 怎麼設定。Meta-framework 把這些 convention 加進去，讓你有一個「完整的 web 應用」起點。
React 本身：
❌ 路由（你自己決定用 React Router 哪個版本）
❌ 資料取得（fetch / axios / React Query，你決定）
❌ SSR（你自己設定 Node.js server）
❌ Static generation（你自己搞）
Next.js：
✅ 檔案系統路由（`app/users/[id]/page.tsx` 就是一個路由）
✅ Server Component / Client Component 分工
✅ Server Action（在 component 裡直接寫 server 端邏輯）
✅ Static / Dynamic / ISR 生成策略
純後端 Framework 是什麼
Express、Fastify、NestJS、FastAPI、Spring Boot——這些是純後端 API framework。它們的設計假設是：這個服務的工作是「接 HTTP 請求、處理商業邏輯、回傳資料」，UI 是別的東西（可能是 React / Vue 前端、可能是 mobile app）。
Express：
✅ 路由（URL → handler 的對應）
✅ Middleware chain
✅ JSON response
❌ UI layer（根本不管）
❌ SSR HTML（不是它的工作）
❌ Static file optimization（交給 CDN）
兩者的架構哲學是相反的
Meta-framework 的哲學：server 是 UI 的延伸。
Next.js 的 Server Component 和 Server Action 讓你在 React component 裡直接寫資料庫查詢：
// Next.js App Router — Server Component
// 這段程式碼跑在 server，直接查 DB，不需要 API endpoint
export default async function UserPage({ params }: { params: { id: string } }) {
const user = await db.user.findUnique({ where: { id: params.id } });
// user 直接傳給 component，不需要 fetch API
return <UserProfile user={user} />;
}後端 framework 的哲學：server 是獨立的服務，UI 透過明確的 API 契約和 server 溝通：
// Express — API endpoint
app.get('/users/:id', authenticate, async (req, res) => {
const user = await userService.findById(req.params.id);
res.json(user);
// 不管誰來呼叫——React 前端、Vue 前端、mobile app、第三方都可以
});什麼情況選 Meta-framework
你做的是「一個 web 應用，前端和後端緊密耦合」：
- 內容網站、行銷網站、電商前台（SEO 是需求 → SSR 很重要）
- Admin 後台（只有你的 React 前端會呼叫這個 server）
- 小型 SaaS（前後端同一個 codebase，一個 Next.js 專案全包）
- 快速 prototype（不需要分離的 API server）
Meta-framework 讓「全端工程師」可以在同一個 codebase 裡同時寫 UI 和 data layer，部署也簡單（Vercel / Netlify 一鍵）。
什麼情況選純後端 Framework
你做的是「一個 API service，服務多個 client」：
- 你的後端要同時服務 web 前端、iOS app、Android app
- B2B API（第三方開發者呼叫）
- Microservice（一個服務只做一件事，被多個其他服務呼叫）
- 效能關鍵的 API（不需要 SSR overhead，只要純 JSON）
純後端 framework 讓你的 API 有明確的 contract，任何 client 都可以呼叫，獨立 scale，獨立部署。
不懂 Node.js 去玩 Next.js 的坑
Meta-framework 把很多 server 細節藏起來了——你只要寫 React component 和 async function，不用管 HTTP header、middleware、session 怎麼工作。
這在大多數情況下是好事，但當你遇到邊界問題時會非常痛：
- CORS 問題：不懂 CORS 的人看到 “blocked by CORS policy” 完全不知道為什麼，因為 Next.js 沒有讓你明確設定 CORS middleware
- Cookie / Session：Server Action 的 cookie 操作和傳統 API server 的方式不一樣，不懂 HTTP cookie 機制的人會寫出 bug
- Streaming / Suspense：React 18 的 Suspense streaming 背後是 Node.js stream，出問題時 debug 需要懂底層
Meta-framework 是「藏複雜度」，不是「消滅複雜度」。懂底層讓你在出問題時知道去哪裡找答案；不懂底層讓你遇到框架邊界就卡住。
常見的誤用
誤用一：用 Next.js API Routes 做微服務
Next.js 的 API Routes 可以寫後端邏輯，但它是給「同一個 Next.js 應用的 server 端請求」設計的，不是給「獨立部署、被多個 client 呼叫的 API service」設計的。把 Next.js API Routes 當完整的 API server 用，會遇到 connection pool 管理、graceful shutdown、log 設計等問題，而 Next.js 的文件對這些沒有明確答案。
誤用二：用 Express 做全端
Express 做全端（API + server-side rendering HTML）可以，但你要自己實作 SSR、路由、靜態資源最佳化——這就是在重新發明 Next.js。