2026-10-29 · 技術
發版後用戶還看到舊頁面，多半不是CDN壞了，而是快取層級比你想像的多。本文講清邊緣、中間層與瀏覽器快取的關係，URL、目錄、全站三種重新整理的適用場景，以及從設計上避免依賴重新整理的做法。
發版之後最常見的投訴是：我這邊還是舊頁面。運營看到的是舊價格，測試看到的是舊按鈕，而你在伺服器上確認檔案已經換了。 這不是 CDN 壞了，多數情況是快取層級比你想像的多。 一次請求從使用者到源站，中間至少有四層可能留下舊內容：瀏覽器本地快取、CDN 邊緣節點、CDN 的中間層（父層或回源層），以及源站前面的反向代理或物件儲存。你重新整理了一次，只代表其中一層收到了指令。 從響應頭能看出命中在哪一層。看 Age 判斷內容在邊緣放了多久，看 X-Cache、CF-Cache-Status 這類欄位判斷是命中還是回源，再看 Via 裡有沒有中間層。帶著這些資訊去提工單，比一句“我這邊沒更新”有效得多。 三種重新整理方式，用錯場景就會出問題。 按 URL 重新整理最精準，適合單個頁面、單張圖片、一個 JS 檔案。提交後一般幾十秒到幾分鐘生效，量小、風險低，日常發版優先用它。 按目錄重新整理適合整站改版，比如活動頁整體換版。要注意目錄字首是包含關係，刷 /act/ 會把下面所有檔案一起刷掉。 全站重新整理是核武器，只在極端情況用。它會讓所有節點同時回源，源站瞬間承受全網請求，頻寬小的機器很容易被打掛。真要用，先確認源站能扛住，或者配合預熱。 比重新整理更重要的是在設計階段就別依賴重新整理。 靜態資源帶檔案指紋，app.2f3a91.js 這種命名，內容變了 URL 就變，天然不需要重新整理，還可以設一年長快取；HTML 入口給短快取，比如一到五分鐘，保證改版能快速生效；介面類請求明確 no-cache 或短 TTL，別讓價格、庫存被快取住。 還有一個常被忽略的點：發版時的灰度。先刷一個測試域名或一部分節點，確認頁面正常再全量，能避免刷完發現樣式崩了、全網使用者都看到的尷尬。 CDN 快取不是玄學，搞清楚層級、看懂響應頭、用對重新整理方式，大部分“沒更新”的問題十分鐘內能定位。 如果你的站點同時面向國內和東南亞使用者，加速IDC 的 CDN 加速覆蓋東南亞 12 個節點，支援按 URL 與目錄重新整理，配合彈性源站頻寬，發版時更從容。
