題幹與適用場景
檔案服務需要邊讀邊傳輸，伺服器在開始回應時不知道最終位元組數或摘要。產品希望客戶端收到末尾中繼資料後驗證完整性，但請求可能經過 CDN、反向代理與不同版本的 HTTP。請設計回應契約，說明哪些資訊能放在 Trailer、如何宣告與驗證、如何記錄失敗，並給出無法接收 Trailer 時的替代方案。
這道題適合後端、閘道與基礎設施職位。核心不是記住一個回應標頭名稱，而是判斷「必須在標頭決定的中繼資料」與「只能在串流結束後得到的中繼資料」，再為中間層遺失、連線中斷與客戶端不支援設計安全語義。
面試官考察點
強回答會先區分完整性摘要、簽章、長度與快取控制的時序，再用 Trailer: Digest（或明確註冊過的欄位）宣告可能出現的尾部欄位。它會說明 HTTP/1.1 的分塊傳輸只是實作方式，Trailer 可能被中間層丟棄；客戶端必須把「沒有收到摘要」「摘要不匹配」與「傳輸未完成」區分開，不能把串流結束當作驗證成功。
回答前需要釐清的問題
- 摘要用於偵測傳輸損壞、驗證來源簽章，還是兩者都要？威脅模型是否包含惡意代理？
- 客戶端是瀏覽器、原生 SDK、內部服務還是可控的 Node.js 客戶端？能否升級？
- 請求會經過哪些 HTTP 版本、CDN、快取與壓縮層，是否允許緩衝整個回應？
- 失敗時能否重新下載，是否有物件版本、Range 請求或斷點續傳？
- 是否必須支援快取，摘要是針對編碼前內容還是線上的表示形式？
30 秒回答框架
「我會把摘要定義為表示資料的完整性中繼資料，使用已定義允許出現在 Trailer 的欄位，並在標頭送出 Trailer 宣告。伺服器邊串流傳送邊計算摘要，結束時寫入 Trailer；客戶端只有在讀到完整串流與摘要且驗證相符時才標記成功。由於代理可能丟棄 Trailer，我不會讓它承擔唯一的業務必要語義；不支援的客戶端改用預先計算的摘要、帶簽章的 manifest 或重新下載驗證。傳輸中斷、摘要缺失與不匹配都進入可觀測的失敗狀態。」
分步驟深入解答
第一步：定義摘要與表示範圍
先確定摘要涵蓋的位元組。通常摘要針對解碼後的表示資料；若伺服器傳送壓縮內容，客戶端必須知道驗證的是壓縮後位元組還是解壓後位元組。把演算法、編碼與物件版本放進協定契約，避免同一欄位在不同端含義漂移。
若摘要還要抵抗惡意替換，需要簽章或可信 manifest；普通摘要只能發現意外損壞，不能證明傳送方身分。長度、路由、認證與快取控制等接收方在讀正文前就要決定的欄位，不應依賴 Trailer。
第二步：宣告 Trailer 與選擇傳輸
HTTP 規範定義 Trailer 欄位為正文之後才知道的可選中繼資料，並要求傳送方用 Trailer 標頭列出預計出現的欄位名。HTTP/1.1 常用 chunked framing 承載尾部；HTTP/2 也有獨立的 trailer section，不應把概念誤寫成只有 chunked 才存在。
HTTP/1.1 200 OK
Content-Type: application/octet-stream
Trailer: Digest
Transfer-Encoding: chunked
<streamed bytes>
0
Digest: sha-256=:<base64-value>:示例中的尖括號只是佔位符並放在程式碼區塊中；正式協定應使用已註冊且允許作為 Trailer 的欄位語法。不要把任意自訂欄位塞進尾部後假設代理會原樣轉送。
第三步：定義客戶端狀態機
客戶端狀態至少包括 reading、complete-awaiting-trailer、verified、missing-trailer、mismatch 與 truncated。只有正文讀完、底層訊息完成且摘要匹配時才交付「可用檔案」；串流連線關閉但沒有完整訊息時必須標記截斷。
瀏覽器 Fetch、行動 SDK 與內部服務對 Trailer 的暴露能力不同。能力探測不能只看請求的 TE: trailers，因為它表示願意保留尾部，不保證能處理某個欄位。對不可控客戶端，預先提供物件摘要或 manifest 更可靠。
第四步：處理代理與快取
RFC 9110 明確提醒中間層可能丟棄 Trailer，跨 HTTP 版本轉送時還可能緩衝或改寫。CDN 或代理應在相容性測試中驗證：是否保留宣告、是否保留實際尾部、壓縮後摘要是否仍對應客戶端看到的位元組、快取命中時是否重現同樣中繼資料。
快取鍵要包含物件版本與表示編碼。若快取沒有保留 Trailer，命中回應不能聲稱已完成驗證；可以讓快取保存 manifest，或改用預先計算的 Digest／簽章欄位。
第五步：應對失敗與重試
摘要缺失不是摘要匹配，連線提前關閉也不是空摘要。客戶端應保存失敗原因、物件版本與已接收位元組數，伺服器記錄請求 ID、傳輸時長與代理鏈摘要。對可重試的下載使用 Range 請求或新版本 URL，避免把損壞的部分檔案當作成功結果。
伺服器若在計算摘要或傳送尾部前崩潰，不能補發一個看似正常的 200。下游可以把未驗證物件放入隔離區，等待重新下載或透過可信 manifest 驗證。
第六步：選擇降級協定
對小檔案可預先計算摘要並放在普通回應欄位；對大檔案可發布簽章 manifest，包含物件版本、長度、摘要與過期時間。分塊上傳或物件儲存通常已經有分片校驗，可把最終摘要放在中繼資料服務中，而不把關鍵驗收綁定到 Trailer。
降級必須在同一搜尋／下載請求中保持明確：客戶端知道自己拿到的是 verified-by-trailer、verified-by-manifest 或 unverified，不能靜默混用。
第七步：權限、簽章與隱私
摘要本身通常不敏感，但物件名、版本與簽章中繼資料可能洩露資源存在性。按物件授權回傳 manifest，簽章金鑰只在伺服器，驗證公鑰透過可信配置分發。不要把使用者權杖、內部路徑或堆疊寫進 Trailer。
若使用數位簽章，簽章涵蓋範圍、規範化與過期策略必須固定；中間層重新壓縮或轉碼會改變被簽章的位元組，伺服器應明確簽章的是資源版本還是具體 representation。
第八步：驗證與觀測
用可控客戶端與真實代理矩陣測試：HTTP/1.1 chunked、HTTP/2、壓縮、快取命中、Trailer 被丟棄、正文截斷、摘要錯誤、重複欄位與大檔案背壓。Node.js 文件說明 response.addTrailers() 需要先送出 Trailer 標頭，且非 chunked 回應可能靜默丟棄尾部，這些條件應成為整合測試斷言。
指標至少包括摘要缺失率、不匹配率、截斷率、重試成功率、代理版本分布與驗證耗時。告警要區分單一客戶端不支援與某條 CDN 路徑系統性丟棄，避免把相容性降級誤報成內容損壞。
設計取捨與邊界
Trailer 適合邊生成邊傳輸、結束時才知道的完整性或處理狀態，能避免為計算摘要而先緩衝整個檔案。代價是中間層與客戶端支援不一致，且不能承載必須在正文前決定的路由、認證、長度或快取語義。
預先計算摘要或 manifest 更容易快取、重試與跨客戶端驗證，但會增加中繼資料讀取與版本同步。簽章比普通摘要提供更強的來源保證，卻需要金鑰輪換、規範化與過期管理。選擇依據是檔案生成延遲、客戶端可控程度、代理鏈與威脅模型。
落地計畫與證據
先在內部 SDK 與單條 CDN 路徑啟用 Trailer，記錄保留率與驗證結果；同時提供 manifest 降級，並讓客戶端明確上報驗證方式。通過 HTTP/1.1、HTTP/2、壓縮與快取測試後，再擴大到不可控客戶端；若關鍵鏈路丟棄尾部，就把 manifest 設為必要路徑。
RFC 9110 說明 Trailer 可承載完整性檢查、簽章與後處理狀態，也明確限制、宣告與中間層丟棄風險；Node.js 文件給出 Trailer 與 addTrailers() 的傳送條件；公開 REST API 面試指南則強調契約、冪等、錯誤與可觀測性。三者共同支撐本題的協定選擇與驗證重點。
常見誤區與追問
把 Trailer 當作「遲到的回應標頭」
它們在訊息處理時機與中間層語義上不同。只能把欄位定義允許出現在 Trailer 的中繼資料放到尾部，並獨立保存與處理。
沒有送出 Trailer 標頭
許多實作不會穩定發出或暴露尾部欄位。先宣告欄位名，再用客戶端與代理驗證實際保留結果。
只檢查連線是否關閉
連線關閉可能表示截斷。必須同時確認訊息完整、尾部存在且摘要匹配，才能把檔案交付下游。
把摘要當作簽章
摘要能發現偶然損壞，不能抵抗擁有寫入權限的攻擊者替換內容。需要身分保證時使用簽章 manifest 與可信金鑰分發。
如果 CDN 丟棄 Trailer 怎麼辦？
保持物件未驗證狀態，改用預先計算的摘要或 manifest，並監控該路徑的丟棄率。不要靜默把缺失摘要當成成功。