題幹與適用場景
來源站已能在最終回應前傳送 103 與 Link，但正式環境鏈路還經過 TLS 終止層、負載平衡器、反向代理與 CDN。回答須設計端到端相容矩陣、灰度開關、透明降級與觀測方案，並證明 1xx 確實抵達受支援的瀏覽器。
面試官考察點
強回答會區分暫時與最終回應，選擇高置信度關鍵資源，說明 HTTP/2、HTTP/3、代理與 CDN 相容性，並設定不支援 103 時的透明降級。也要討論錯誤資源提示、快取、跨源連線風險與真實指標。
回答前需要釐清的問題
- 伺服器多早、以多高置信度確定資源清單？
- 客戶端、TLS 終止層、反向代理與 CDN 是否保留 1xx？
- 資源是否帶版本雜湊，是否需要跨源
preconnect？ - 目標是降低 LCP、改善 CSS 與字型到達，還是縮短等待空窗？
- 失敗、快取命中及不支援 103 的客戶端如何觀察與回退？
30 秒回答框架
我會在最終回應前，針對少量高置信度資源送出 103 與 Link，之後仍送出正常最終回應。資源使用版本化 URL，跨源連線只指向受信任網域。代理或客戶端忽略 103 時頁面照常工作，不把它當作成功或快取結果。先以 trace 與 RUM 對照 LCP、資源發現、重複下載與錯誤率，再逐步擴大。
分步深入解答
第一步：理解訊息時序
103 是資訊性暫時回應，後面必須有最終回應。它可在伺服器思考期間傳遞 Link: </app.css>; rel=preload; as=style 等提示；是否執行由協定棧、瀏覽器與策略決定，業務不能依賴它完成。
第二步：選擇資源
只提示幾乎必需、體積合理且 URL 穩定的 CSS、字型或預連線。不要提示低機率圖片、個人化腳本或權限資源，以免浪費頻寬與造成錯誤預取。
HTTP/1.1 103 Early Hints
Link: </app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect
HTTP/1.1 200 OK
Content-Type: text/html; charset=utf-8第三步：處理代理與降級
在真實入口驗證負載平衡器、TLS 終止、CDN 與瀏覽器是否轉送或消費 103。忽略 103 時，最終回應仍要有普通資源引用，頁面不能失敗。
第四步：控制快取與安全邊界
提示只可對應目前請求上下文的資源。使用內容雜湊與正確 Cache-Control，不要由使用者輸入生成任意 Link。跨源 preconnect 只允許可信來源與必要參數。
第五步：避免錯誤預載
若驗證、實驗分組或地區邏輯會改變資源，等到更高置信度或不送提示。若最終不再引用已提示資源，瀏覽器可能已浪費下載，須用指標衡量代價。
第六步：建立觀測與回滾
記錄是否送出 103、最終狀態、資源發現、快取命中、重複位元組與代理差異。用 feature flag 按路徑或流量啟用，惡化時停止提示而不影響最終 HTML。
設計取捨與邊界
103 與 preload 連結
103 提前傳送提示，HTML 的普通 link 仍是最終權威引用。兩處不一致會重複下載或衝突。提示不能取代 CSP、完整性與權限策略。
HTTP 版本與中間層
RFC 定義 103 語意，但代理鏈路可能丟棄 1xx。應按實際 HTTP/2、HTTP/3、CDN 與客戶端組合測量，保留無 103 基線。
落地計畫與證據
分階段發布
先在單一路徑提示靜態 CSS，核對最終回應與資源引用，再擴大到字型或安全預連線。每階段保留關閉開關，分開比較首次、快取與慢網使用者。
指標與驗收
關注 LCP、資源發現時間、重複下載、快取命中、4xx/5xx 與頻寬。以開發者工具、邊緣日誌與 RUM 三方核對，不能只看伺服器送出日誌。
常見誤區與追問
誤區：把 103 當最終成功
業務狀態、快取與錯誤處理以最終回應為準；103 遺失不應導致失敗。
誤區：提示所有資源
低置信度資源浪費頻寬與連線，優先提示少量關鍵且穩定的資源。
誤區：只在本地直連測試
生產 CDN、代理與 TLS 終止可能改變 1xx 行為，必須端到端驗證。
追問：不支援 103 怎麼辦？
依賴最終 HTML 的普通引用與原有快取策略，保持功能正確，只失去潛在效能收益。
追問：如何證明值得保留？
以分流實驗比較 LCP、資源發現、重複位元組、錯誤率與頻寬成本，並按快取與網路條件分層。