題幹與適用場景
團隊發現快取閘道會附加 Warning: 110 - "Response is stale" 和 Warning: 111 - "Revalidation failed"。瀏覽器和下游服務並不穩定地展示這些欄位，新的標準也不再推薦使用它們。請說明 Warning 的歷史語義、快取驗證邊界、替代欄位和無損遷移步驟。
這道題適合後端、閘道、CDN 和平台職位。重點是能區分協定元資料、使用者錯誤和內部可觀測性，不要只把棄用欄位換成另一個自訂回應標頭。
面試官考察點
強回答會指出 Warning 可描述訊息問題，快取相關 1xx 警告在成功驗證後可被快取刪除；但該欄位已被棄用，因為生成和呈現都不廣泛，部分資訊可由 Age 等其他欄位推斷。候選人還應保留快取契約，用 Cache-Control、Date、Age、狀態碼和日誌／指標表達事實，避免客戶端依賴自由文字。
回答前需要釐清的問題
- Warning 是源站、共享快取還是邊緣閘道生成的？是否有多級代理？
- 110、111 只是診斷，還是客戶端據此改變了業務行為？
- 目前回應是否包含
Date、Age、Cache-Control、ETag和Last-Modified？ - 需要相容哪些舊客戶端，能否先雙寫一段時間？
- 「新鮮」「過期」「重新驗證失敗」分別要給使用者、業務和運維誰看？
30 秒回答框架
「我會先把 Warning 當成歷史快取診斷，而不是穩定的使用者錯誤契約。110 表示快取回應過期，111 表示重新驗證失敗，但欄位已棄用且不適合承載自由文字。先盤點消費者和多級代理，用 Cache-Control、Date、Age、驗證器和結構化指標表達真實狀態；短期可在受控範圍雙寫相容欄位，觀察客戶端行為後刪除 Warning，並用快取命中、過期服務、重新驗證失敗率和錯誤預算驗證遷移。」
分步驟深入解答
第一步：還原 Warning 的歷史職責
Warning 是請求和回應標頭，可包含三位警告碼、生成代理和文字。快取相關的 110、111 分別描述回應過期和重新驗證失敗；它們不是 HTTP 狀態碼，也不等同於 4xx 或 5xx。多個代理可能追加欄位，因此自由文字的來源和可信度並不穩定。
第二步：說明為什麼要遷移
MDN 將 Warning 標為棄用，原因是它沒有被廣泛生成或呈現，相關標準已移除這類通用警告的推薦用途。繼續依賴它會把快取診斷綁在不穩定的文字格式上，還可能讓跨代理的重複、重排和過濾變得不可見。遷移應先證明沒有客戶端把它當作業務訊號。
第三步：用標準快取欄位表達事實
Date 是回應生成時間，Age 表示共享快取中的近似年齡；Cache-Control 定義新鮮度和重新驗證要求，ETag 或 Last-Modified 供條件請求使用。它們共同描述快取狀態，不能用一個自訂 X-Warning 文字取代。源站仍應返回正確的 Vary，避免把不同請求的表示混在一起。
第四步：把診斷移到可觀測性
閘道在內部記錄結構化事件，例如 cache_status=stale、revalidation=failed、upstream=timeout、命中層級和請求追蹤 ID。日誌要避免記錄敏感 URL 查詢參數；指標按路由、快取鍵族和上游錯誤類型聚合。回應本文只承擔使用者需要理解的狀態，運維細節留在受控系統。
第五步：設計相容雙寫窗口
先在影子流量或小比例路由上停止消費 Warning，確認沒有 SDK、腳本或代理規則依賴它。若確有舊客戶端，短期保留 Warning，同時發布替代欄位或客戶端升級指南；替代欄位必須有穩定枚舉和版本契約，不能複製任意文字。為雙寫設定明確截止時間，避免相容層永久存在。
第六步：處理多級快取和驗證失敗
重新驗證失敗不一定意味著源站不可用，可能是網路逾時、條件請求被拒絕或上游返回 5xx。閘道要決定是提供舊的陳舊回應、返回錯誤，還是按 stale-if-error 等策略服務舊內容，並記錄選擇原因。不能因為刪除 Warning 就掩蓋過期服務或無限重試。
第七步：區分 103 Early Hints 等不同目的
103 Early Hints 是在最終回應前提示可能需要的資源，主要配合 Link 標頭進行預連線或預載入；它不是快取過期警告，也不取代 Age 或 Cache-Control。面試中應明確不同欄位的時序、消費者和失敗語義，避免把所有「提示」都塞進 Warning。
第八步：分階段下線並驗證
遷移前後比較 Warning 讀取量、快取命中率、stale 服務比例、條件請求成功率、源站錯誤率、P95 延遲和客戶端錯誤。先在單一快取層關閉，再擴展到全鏈路；確認舊客戶端無異常後移除生成邏輯、文件和告警規則。回滾開關應只恢復相容輸出，不恢復對 Warning 的業務依賴。
設計取捨與邊界
保留 Warning 的短期相容成本低，但會延長不穩定契約和排障歧義。立即刪除可減少協定噪音，卻可能打斷遺留腳本。最安全的遷移是先觀察真實依賴，再用標準快取欄位和結構化可觀測性承接需求。
不要把 Age 解釋成源站生成時間，也不要把 Cache-Control: no-cache 誤解為禁止快取；它要求重用前重新驗證。快取策略、驗證器和錯誤回應必須結合業務可接受的新鮮度共同設計。
落地計畫與證據
第一週匯出邊緣、共享快取和客戶端對 Warning 的讀取路徑，建立按路由和快取層的基線。第二步在一個無關鍵業務依賴的路由雙寫結構化指標，比較 Age、條件請求和錯誤率。第三步按快取層逐步關閉 Warning，並保留一鍵恢復相容輸出的配置。
驗收條件包括：沒有生產客戶端讀取 Warning；快取命中和重新驗證成功率不下降；stale-if-error 次數有解釋；日誌與指標可按追蹤 ID 關聯；文件、SDK 和告警規則已同步更新。
常見誤區與追問
把 110 當成 4xx 或 5xx
110 是歷史 Warning 代碼，不是回應狀態碼。業務錯誤應由狀態碼和回應契約表達，快取診斷由指標表達。
用自訂 X-Warning 複製舊問題
自由文字、代理追加和版本相容仍會造成同樣的不確定性。若必須相容，應使用穩定枚舉、版本和明確消費者。
只刪除回應標頭不補可觀測性
刪除欄位不會修復過期服務或重新驗證失敗。先建立快取狀態指標、追蹤和告警，再移除外部標頭。
把 103 Early Hints 當作快取警告
103 的時序和用途是提前提示資源，不能表達快取新鮮度或驗證失敗。應分別設計欄位和處理路徑。
如何證明可以下線？
觀察客戶端讀取量、代理配置、錯誤率和關鍵快取指標，執行雙寫窗口並在單層灰度後擴展。沒有依賴證據時不要直接全網刪除。