SSG、ISR、SSR：一個站三種渲染，逐路由挑

「SSR 還是 SSG？」是個假問題——正確的問題是每一條路由該用哪種。這個站用 Nuxt 的 routeRules 混搭三種策略，值得把決策過程記下來。

三種模式，三種取捨

• prerender（SSG）：build 時生一次 HTML。最快、最省，但內容凍結在 build 那一刻——連 build 當下 API 掛掉都會凍出一頁空列表。適合首頁、關於頁這種改版才變的頁。
• swr（自架版 ISR）：第一次請求時 SSR，把 HTML 快取 N 秒；過期後先回舊的、背景重生。讀者永遠拿到即時回應，內容最多舊 N 秒。筆記列表與內文都用它（60 秒）。
• 純 SSR：每次請求都算。這個站沒有頁面需要——這也是重點，預設不該是它。

routeRules: {
  '/':            { prerender: true },
  '/garden':      { swr: 60 },
  '/garden/**':   { swr: 60 },
  '/sitemap.xml': { swr: 600 },
}

一個部署現實：nitro 的 isr 規則只在 Vercel/Netlify 生效，自己架 node-server 時 swr 才是可攜的等價物。

swr 的連鎖效應：活資料要分流

HTML 被快取 60 秒，代表頁面裡的即時數字不能烤進 HTML。到訪計數、澆灌數這些活資料一律 client 端另外抓，SSR 的佔位用固定尺寸撐住（零 CLS）。瀏覽計數也因此必須是 client beacon——swr 命中時根本不會有請求打到 API，伺服器端計數永遠低估。

SSR 的隱形身分：它是你的頭號 API 消費者

SSR 伺服器打 API 用的是伺服器自己的 IP——所有訪客的首次載入共用同一個來源。這件事在限流上炸出過一場429 誤報 404 的慘案，教訓是：設計 API 限流時，SSR 不是一個普通用戶，它是站在你家門口的巨人。