Cache 快取

把常用資料暫存起來，讓下次讀取更快。

先用一句話理解

把常用資料暫存起來，讓下次讀取更快。

打個比方

像把常用文件放桌上，不用每次都去倉庫拿。

什麼時候會遇到

資料讀取慢、流量高、SEO 頁面很多、API 成本高時。

再往深一點看

Cache（快取）是把已經算好或取得的結果暫存起來，下次同樣的請求直接回傳暫存值，跳過重新查資料庫或呼叫外部 API 的成本。它和 CDN 解決的問題不同：CDN 快取的是靜態檔案（圖片、JS）並分發到全球節點，cache 快取的是「計算或查詢的結果」（資料庫查詢結果、API 回應、渲染好的 HTML），它存在伺服器記憶體或 Redis 這類快取資料庫裡。快取的核心難題是失效（invalidation）：什麼時候該清掉舊的快取換新的？常見策略有三種：TTL（設定存活時間，時間到自動失效）、事件觸發失效（資料更新時主動清除對應快取）、版本雜湊（URL 帶 hash，資源更新時 URL 就不同，永遠不衝突）。Next.js 的 `fetch` 函式內建快取行為，`revalidate` 選項控制多久重新抓一次，是初學者最常遇到的快取設定。

舉個例子

你的部落格首頁要列出最新文章，每次載入都查一次資料庫太慢也太貴。你在 Next.js 的 `fetch` 加上 `{ next: { revalidate: 60 } }`，讓資料最多快取 60 秒——在這 60 秒內所有訪客都從快取取得同一份結果，60 秒後下一個請求才重新查資料庫並更新快取。

常見誤解

- Next.js 預設會快取 fetch 的結果，你更新了資料庫裡的文章標題，但頁面顯示的還是舊標題，以為是資料庫沒寫進去，查了半天才發現是 fetch 快取沒失效。
- 對帶有使用者個人資訊的 API 回應（例如帳戶餘額、私人訊息）設了全域快取，導致 A 使用者看到 B 使用者的快取資料，造成資料洩漏。
- 快取設定太積極（TTL 設幾天），上線緊急修 bug 後使用者還是看到有 bug 的舊版快取頁面，要到 Vercel 或 Cloudflare 後台手動清快取才解決。