Vercel 在 2026 年 10 月 30 日宣布，原本供 Next.js fetch 快取與 unstable_cache 使用的 Data Cache 將併入 Runtime Cache。對既有專案而言，這不是需要立刻重寫 API 的框架破壞性更新；官方表示各版本會在不改程式碼的情況下切換。但它確實改變了儲存配置、觀測方式與費用邊界：先前未計費的 Data Cache 讀寫，遷移後會依 Runtime Cache 的區域費率計算。

因此，這次變動不能只交給開發者確認「網站還能開」。產品負責人、維運與財務應共同確認快取讀寫量、來源資料庫負載、遷移日期與費用警示。關閉快取也不是免費的捷徑，因為請求會回到 CMS、資料庫或第三方 API，可能把成本與延遲移到另一個系統。

先確認時程、方案與真正受影響的 API

Vercel 的 10 月 30 日公告指出，當日以後建立的團隊預設使用 Runtime Cache；既有 Hobby 團隊預計在 2026 年 11 月 29 日遷移，Pro 團隊會收到個別遷移與計費生效通知，Enterprise 則由客戶團隊聯繫。既有 Hobby 與 Pro 團隊也可提前在 CDN 設定加入，但一旦提前切換，Runtime Cache 費率就開始適用。

公告同時說明，Next.js 的 fetch caching 與 unstable_cache 不需要為這次切換改寫。這句話只代表 API 介面維持，不代表成本與行為不必驗收。應在程式庫搜尋 unstable_cache、帶有快取選項的 fetch、revalidateTag、revalidatePath，以及框架或共用套件封裝的快取函式；不要只搜尋頁面元件，漏掉 Server Action、背景同步與建置階段。

截至 2026 年 10 月 31 日，官方公告列出的起始費率為每百萬讀取單位 0.40 美元、每百萬寫入單位 4 美元，並會依區域不同；Hobby 每月包含全團隊 100 萬讀取單位與 20 萬寫入單位，Pro 用量先由每月 20 美元 infrastructure credit 抵扣。實際預估仍應查閱當期的區域定價文件、專案執行區域與帳務頁面，不能把起始價直接當成所有地區的固定報價。

用觀測資料做基準，不用頁面瀏覽量猜成本

遷移前先匯出至少一個完整營運週期的 Data Cache 讀取、寫入、儲存量、命中率與重新驗證原因，並在圖表標記發布、促銷、爬蟲流量與批次匯入時間。頁面瀏覽一次可能觸發多個 cache key，也可能完全由 CDN 回應；用 PV 乘單價容易高估或低估。

Vercel 的架構文章說明 Runtime Cache 是分區域的快取。命中會在程式執行區域讀取；未命中時，由應用取得或計算資料後寫入該區域。標籤失效會透過共用基礎設施傳播，但每個區域仍有自己的快取內容。多區域 Functions 因此可能對相同資料產生多次讀寫；評估時要把部署區域納入，而不是只看單一 key 的理論 TTL。

建立一張清單，至少記錄 key 類型、資料來源、平均大小、讀寫頻率、TTL、標籤、失效事件與容許舊資料時間。商品目錄、網站導覽與公開文章適合較長快取；即時庫存、價格、權限與會員資料則應先判斷能否快取，以及錯誤共用資料的風險。若快取 key 含隨機值、時間戳或過細的使用者識別，命中率低但寫入持續增加，會同時浪費成本與儲存。

最佳化的順序是減少無效寫入，再調整讀取

先找「寫了但很少再讀」的項目。常見原因包括 TTL 太短、每次部署產生新 key、把完整查詢參數都放入 key、相同資料分成太多標籤，或在請求路徑無條件重建快取。對變動可預測的內容，延長 TTL 並由 CMS webhook 做 on-demand revalidation，通常比每分鐘重新驗證更可控；但 webhook 必須有簽章、重試與重複事件處理。

再處理讀取。不要在同一個 request 的多層元件重複取得相同 key；可在請求範圍合併工作，並確認框架本身是否已去重。資料若只在一次請求內重用，未必需要跨請求 Runtime Cache。相反地，直接關掉 fetch 或 unstable_cache 快取，會讓每次請求回源，應先對來源 API 的速率限制、資料庫連線與費用做壓力測試。

標籤失效也要避免過大與過小。全站共用一個標籤會讓單一商品更新造成大量 miss；每筆資料建立多個不一致標籤，又會讓更新漏失。可以用「資料類型＋穩定識別碼」設計，例如商品集合與單品各有一層，並讓更新事件清楚指出要失效哪些範圍。

遷移驗收要同時看正確性、負載與帳務

在 Preview 或非關鍵環境先建立基準案例：首次請求應 miss、第二次應 hit、更新來源後應在預期時點失效，失效後內容正確且不會形成併發回源尖峰。測試熱門頁、長尾頁、多語系、草稿預覽與登入狀態，確認個人資料不會被共用 key 快取給其他人。

正式切換後，至少觀察一個與基準相同的週期。比較 Runtime Cache 讀寫單位、命中率、來源資料庫 QPS、外部 API 呼叫、函式延遲與錯誤率；同時設定用量與費用警示。若讀寫突然增加，應能對回發布版本、路由或特定 key 類型，而不是等月底帳單才追查。

若評估替代方案，Cloudflare、Railway、自架 VPS 或獨立 Redis 都不是一比一換掉 Vercel Cache。要比較的是部署方式、Next.js 相容性、跨區域一致性、失效機制、資料持久性、監控、備份與維運責任。自架快取可增加控制，但容量、故障切換、安全更新與值班會轉成自己的工作。

這次遷移最合理的交付物，是一份可重跑的用量基準、快取 key 與標籤清單、成本區間、切換驗收和回復方案。程式碼不必改，不代表專案不必準備；先用實際讀寫證據找出浪費，再決定提前遷移、等待排程或調整架構，才能避免把平台更新變成不可解釋的帳單與來源負載。