試想一間美國維修公司嘅客服助手：後台已經將預約改咗做下晝，助手但係仲顯示朝早。呢個虛構排查例子，唔代表某間公司嘅產品有故障。先唔好急住重寫提示詞：瀏覽器、中間層快取，同應用程式自己嘅快取，都可能影響見到嘅資料。排查應該先問，呢份回答嘅資料喺邊度、幾時攞到，再判斷模型係咪讀錯。

我哋建議同時顯示業務記錄嘅更新時間，同今次讀取嘅時間。兩者答緊唔同問題：記錄幾時改過，應用程式幾時攞到佢。HTTP 快取標準嘅回應存續時間欄位，描述回應產生或者成功驗證之後，估計過咗幾耐，唔係業務記錄嘅修改時間。所以啱啱開咗個頁面，或者回應存續時間好短，都唔可以單憑呢點證明預約仍然有效。

開發者文件講明，回應入面嘅 no cache 容許儲存，但係再次使用之前，一定要向來源網站驗證；no store 就要求快取唔好儲存個回應。唔好將 no cache 理解成從來唔儲存。用邊種策略，應該由工程同資料負責人決定，唔可以叫人工智能靠個名去估。驗證亦唔等於每次都要重新下載完整內容。

開發者文件提醒，快取指令唔會清除中間伺服器已經儲存咗嘅回應。我哋建議排查嗰陣，列出瀏覽器、內容傳遞層同應用程式快取，逐層核對更新或者失效嘅方式。加咗一個回應標頭，唔代表舊副本已經刪除；亦唔好為咗排查，就一律清空同今次問題無關嘅資料。

HTTP 快取標準定義嘅新鮮度，係睇個回應係咪仲喺規定嘅新鮮期入面，唔係業務上嘅即時保證。我哋建議將可以瀏覽嘅狀態，同最終承諾分開：確認預約之前，按業務規則再核對權威來源系統。如果核對唔到，就清楚講明仲未確認。快取設定唔可以代替存取控制或者操作授權。

用虛構預約做測試：先讀取朝早嘅狀態，再喺來源系統改做下晝，觀察正常瀏覽、重新載入，同應用程式快取失效之後嘅結果。記錄今次命中邊一層、實際回應標頭同業務時間，唔好淨係寫重新載入就整好咗。呢個係建議測試方案，未喺客戶系統執行。通過條件要由團隊講清楚，例如確認畫面唔可以將過期副本當成而家嘅承諾。