快取有個很矛盾的地方。網站慢的時候，大家會問怎麼不加快取；文章剛改完卻還看到舊內容，又會開始懷疑是不是快取沒清。兩邊的要求都很合理，只是很難同時把便宜、快速、即時更新全部拿到。
Cloudflare 在 2026 年 7 月推出 Workers Cache，我覺得值得看的是它放的位置：在 Worker 執行之前。也就是請求進來後，如果已經有一份還有效的回應，就直接拿那份回去，連負責處理請求的程式都不用再跑一次。
對一個公開的文章列表，這滿合理的。同一分鐘來了幾百個人，看到的十篇文章可能完全一樣，卻每次都查資料、組回應，想想是有點浪費。第一個請求做好後留一份，後面先共用，少做的那些工作才是快取省下來的東西。
一分鐘可以差多少？#
啟用 Workers Cache 後，可以用熟悉的 HTTP 標頭決定回應保留多久：
Cache-Control: public, max-age=60這份回應可以放進共用快取，60 秒內視為新鮮。它不會每分鐘自動醒來更新，而是在有請求時，依快取的狀態決定要不要重新取得資料。這個標頭也可能被瀏覽器等其他 HTTP 快取使用，不只是 Cloudflare 看得懂。
六十秒聽起來很短，但如果剛按完發布，馬上開首頁卻找不到新文章，第一個反應大概還是「是不是沒成功？」這時系統其實可能完全正常，只是在忠實執行我們自己設的規則。
所以我會先問自己，這個頁面到底能不能晚一分鐘。一般文章列表，我多半能接受；如果希望發布後立刻看見，就得把清除對應快取一起接進發布流程。只設定保存、沒想到更新，後面就會一直靠手動清理救場。
個人資料就不能照抄這個設定了。登入後的訂單如果被當成公開內容共用，那已經不只是「看到舊資料」的問題。更容易漏想的是，命中快取時 Worker 不會執行，原本寫在裡面的權限檢查也可能跟著跳過。哪些回應能被共用，要在開快取前就分清楚。
我會想先拿自己的公開文章列表試，這種頁面夠單純，也看得出前後差別。至於發布後等幾秒才看見新文章，知道原因之後倒還好；真正讓人煩的是不知道它在等什麼，於是重整五次、再重發一次，最後才想起那行 max-age。