MPA、SPA、SSR、SSG、ISR——不是在唸咒語，是前後端對接架構的演進史。
先講結論
沒有最好的架構，只有最適合的。需要 SEO 且內容常更新？SSR 或 ISR。內容不常變？SSG。不需要 SEO 的 Web App？SPA。傳統後台系統？MPA 也還行。選架構之前先問自己這兩個問題：要不要 SEO？內容更新頻率多高？
MPA：古早味但還活著
傳統 MPA（Multi-Page Application）就是每次點連結都整頁刷新。PHP、Rails、Django 產生完整 HTML 直接丟給瀏覽器。
好處是 SEO 天生友好、首屏載入快、實作簡單。壞處是每次換頁都白屏一下，使用者體驗很 2005 年。但說真的，很多後台系統到現在還在用 MPA，因為 PM 不會去看後台的使用者體驗。
AJAX：不用整頁刷新的魔法
2005 年 Google 用 AJAX 做了 Gmail 和 Google Maps，前端界才發現：原來可以局部更新頁面而不用整頁刷新。
fetch('/api/posts')
.then(res => res.json())
.then(posts => {
document.getElementById('posts').innerHTML =
posts.map(p => `<div>${p.title}</div>`).join('');
});AJAX 是從 MPA 到 SPA 的過渡期產物，但它的核心精神——「用 JS 拿資料、動態更新畫面」——直到現在都沒變。
SPA：前端自己當家
SPA（Single-Page Application）首次載入整個 app（HTML + JS Bundle），之後所有導航都由前端 Router 處理，只跟後端拿 JSON 資料。React、Vue、Angular 都是 SPA 框架。
使用者體驗非常流暢——切換頁面不會白屏，感覺像在用 native app。前後端完全分離，各做各的。但代價是：首屏載入慢（要下載一大包 JS）、SEO 困難（爬蟲看到的是空白 HTML）、沒有 JavaScript 就完全不能用。
SSR：兩個世界的好處我都要
SSR（Server-Side Rendering）想要魚與熊掌兼得：首次請求由伺服器渲染 HTML（SEO 友好、首屏快），然後透過 Hydration 把靜態 HTML 變成可互動的 SPA。
Next.js、Nuxt.js、Remix 都是做這件事的。但天下沒有白吃的午餐——伺服器負擔變重、TTFB 比較慢、開發複雜度增加。你得同時搞懂 server 跟 client 兩邊的生命週期，踩坑的機會也翻倍。
SSG：事先蓋好的靜態網站
SSG（Static Site Generation）在 build time 就把所有頁面產生成靜態 HTML，丟到 CDN 上。極快、極安全（沒有伺服器可以被打）、極便宜。
你現在看的這個部落格就是用 Quartz（SSG）蓋的。Gatsby、Hugo 也是同類。缺點是內容更新需要重新 build，頁面很多的時候 build time 會很長。
ISR：SSG 的進化版
ISR（Incremental Static Regeneration）是 Next.js 提出的折衷方案：靜態頁面 + 背景定期更新。
export async function getStaticProps() {
const posts = await fetchPosts();
return {
props: { posts },
revalidate: 60, // 60 秒後背景重新產生
};
}首次請求回傳快取的靜態頁面，過了 revalidate 時間後背景重新產生，下次請求就是新的了。電商產品頁、新聞網站特別適合這種模式。
怎麼選？
| 架構 | 適用場景 | 代表框架 |
|---|---|---|
| MPA | 後台系統 | Laravel, Rails |
| SPA | Web App、Dashboard | React, Vue |
| SSR | 需 SEO + 互動 | Next.js, Nuxt |
| SSG | 部落格、文件站 | Gatsby, Hugo, Quartz |
| ISR | 電商、新聞 | Next.js |
記住：這些架構不是互斥的。現代框架（尤其是 Next.js）允許你在同一個專案裡混用不同的渲染策略——某些頁面用 SSG、某些用 SSR、某些用 CSR。不用把自己框死在一種模式裡。
選架構就像選交通工具：騎腳踏車去超商很合理，騎腳踏車從台北到高雄就有點不合理了。