動態內容加速：登入頁面和業務 API 的快取邊界
動態業務的最佳化不只是提高快取命中率。先區分公開內容與使用者資料，再評估回源、連線複用及真實請求延遲，避免加速規則破壞帳號隔離。
本文目錄
不是每個回應都適合共用
公開文章、版本化指令碼和圖片通常可以設計共用快取；訂單詳情、帳號資料和帶權限的匯出結果則要單獨處理。同一個 URL 回傳什麼內容，可能取決於 Cookie、Authorization、語言或查詢參數。僅憑 .html 或 .json 副檔名決定快取策略，容易把業務差異隱藏起來。
三個回應標頭概念要分清
HTTP 快取規範中的 private 限制共用快取儲存回應；no-store 要求快取不要儲存；no-cache 則允許儲存，但再次使用前需要成功驗證。它們不是同一個含義。Vary 用於聲明影響回應選擇的請求標頭，也不能替代業務鑑權或所有查詢參數的快取鍵設定。
不快取，仍然可以最佳化交付
對於必須回源的請求，建議拆開觀察 DNS、連線建立、TLS、源站運算和回應傳輸的耗時。連線複用、合理逾時和回源鏈路選擇可能改善交付效率，但最終收益需要從實際使用者地區測量。如果主要等待發生在資料庫或第三方介面，應先處理應用依賴。
用兩套帳號驗證隔離
為公開資源、登入介面和敏感頁面各選一個樣本。先用帳號 A 存取，再由帳號 B 和未登入用戶端存取相同位址，核對回應內容、狀態碼與快取行為。隨後修改源站內容，確認重新整理和失效策略符合預期。不要用真實客戶的敏感資料做這類測試。
選型看業務體驗，不只看命中率
對登入入口、SaaS 和 API 服務，建議將成功率、較慢請求的延遲、錯誤重試和回源負載放在同一張驗收清單裡。固定業務頻寬決定傳輸能力，正常流量不計量描述計費方式；二者都不能直接推導出無限並行或任意請求都能快取。