題干與適用場景
這道 HTTP、閘道與效能題適合後端、平台與基礎設施職位。源站在產生最終 HTML 前有一段可預測的等待時間，你需要決定是否傳送 103，以及如何避免錯誤預載、舊用戶端誤處理與快取重複下載。
面試官考察點
- 能否區分 103 的提示語義與最終回應語義。
- 是否會用伺服器思考時間、資源穩定性與快取命中判斷收益。
- 能否設計 HTTP/2 或 HTTP/3 下的漸進回退，而不是把 103 當成必要鏈路。
- 是否能驗證預載沒有造成重複請求、錯誤資源或更高頻寬。
回答前需要釐清的問題
先確認等待來自動態 HTML 產生還是網路傳輸，目標請求是否為頂層導覽，用戶端與代理是否可靠處理 1xx，資源 URL、版本與 as 是否穩定，以及資源是否可快取。若最終回應能立即送出，普通 Link 標頭或 HTML 中的 link 元素更簡單；若資源經常因驗證、重新導向或變體改變，提前提示的錯誤成本會超過收益。
30 秒回答框架
103 是最終回應前的提示，不是頁面結果。源站可以在產生 HTML 時傳送包含 Link: rel=preload 或 preconnect 的 103，讓用戶端並行準備資源；最終 200 仍必須提供權威標頭。只對有明顯伺服器等待、資源預測穩定且 HTTP/2 或 HTTP/3 鏈路可靠的導覽啟用。透過快取、重複下載、LCP、錯誤率與頻寬指標驗證，舊用戶端則回退到普通最終回應。
分步驟深入解答
- 定位可優化的空檔。 先量出請求到最終 HTML 可用之間的伺服器等待。若源站很快回傳 200，103 沒有可利用的時間，應繼續使用最終回應中的普通預載。
- 定義 103 語義。 103 表示伺服器預期最終回應會包含這些標頭欄位，用戶端可以投機準備，但提示不能取代最終回應，也不能改變最終回應的語義處理。
- 選擇提示內容。 優先傳送穩定、關鍵且可快取的 CSS、腳本或連線來源。資源版本、媒體類型與跨源憑證要與最終回應一致；不確定的個人化資源不要提前提示。
- 約束協定與用戶端。 優先在 HTTP/2 或 HTTP/3 上啟用，並確認代理、瀏覽器與監控鏈路能正確處理 1xx。對可能把 103 當最終回應的舊 HTTP/1.1 用戶端關閉或降級。
- 處理最終回應。 最終 200/3xx/4xx 才決定頁面結果。若 103 中的提示後來不正確，用戶端仍以最終回應為準；中介層不能把提示當作最終快取物件。
- 驗證收益與代價。 對照啟用前後首屏 LCP、資源命中、重複下載、頻寬與錯誤率。若重新導向、快取停用或資源變體導致預載浪費，縮小頁面範圍或移除 103。
高品質示範回答
我不會因為 103 看起來更快就全站開啟。先確認動態 HTML 產生有可觀的伺服器等待，而且目標是頂層導覽。若 CSS 與關鍵腳本的 URL、版本、as 與快取屬性穩定，我會在 HTTP/2 或 HTTP/3 上傳送提示：
HTTP/2 103 Early Hints
Link: </style.abc.css>; rel=preload; as=style
Link: </app.abc.js>; rel=preload; as=script
HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
Link: </style.abc.css>; rel=preload; as=style最終回應仍是權威結果，103 不能承諾資源一定會被使用。對舊用戶端、錯誤率高的代理，或資源經常因重新導向與個人化而變化的頁面，我回退到最終回應裡的普通 Link。上線用實驗比較伺服器等待、LCP、快取命中、重複下載、頻寬與 4xx/5xx；如果預載不能覆蓋空檔，就移除 103。
常見錯誤
- 把 103 當作最終狀態 → 用戶端會誤以為頁面已成功 → 說明最終回應才決定結果。
- 複製所有 HTML 資源到 103 → 個人化或非快取資源會重複下載 → 只提示穩定關鍵資源。
- 忽略協定與代理相容性 → 舊用戶端可能錯誤解析 1xx → 優先 HTTP/2/3 並設定回退。
- 只看 LCP 不看頻寬 → 預載浪費可能掩蓋局部收益 → 同時監控重複請求、快取與錯誤。
- 最終回應沒有重複權威標頭 → 提示不是最終元資料 → 在最終回應重新給出需要的
Link。
追問及應對
103 與 HTTP/2 Server Push 有何區別？
103 讓用戶端決定是否預取資源，伺服器只給提示；Server Push 由伺服器主動傳送，可能推送用戶端已有快取的資源。資源快取不穩定時，103 通常更容易避免無謂傳輸。
如果最終回應發生跨源重新導向怎麼辦？
提前建立的連線或資源可能被丟棄，收益變成額外頻寬與連線成本。只對重新導向穩定的入口啟用，並把重新導向率納入實驗指標。
如何處理動態資源版本？
使用已確定的內容雜湊 URL，或只提示能在最終回應中保持一致的版本。無法提前確定時，寧可等待最終 HTML，不要傳送猜測性預載。
為什麼不用所有頁面都發 103？
沒有伺服器等待就沒有可並行化的空檔；深層導覽還可能已命中快取。按入口頁面、協定、快取與實測收益分層開啟。