題干與適用場景
一個製品倉庫用雜湊摘要作為物件位址。請解釋內容定址的優點與邊界，並說明如何從舊雜湊遷移到新雜湊而不破壞用戶端、快取與簽章。
OCI 內容描述符把摘要作為內容識別，並建議在消費不可信來源前重新計算摘要；Git 的雜湊遷移文件展示了逐一儲存庫過渡的思路。面試重點是區分完整性、身分、可用性與遷移相容性，不能把「摘要相同」說成絕對安全證明。
面試官考察點
面試官會看你是否理解雜湊作為位址、去重鍵與校驗值的不同職責，能否說明碰撞、第二原像、原像與演算法降級的邊界，並設計別名、索引、快取、簽章、垃圾回收與回滾。還要判斷何時需要簽章或可信來源，而不是只依賴摘要。
回答前需要釐清的問題
- 物件是容器層、建置產物、備份還是任意使用者檔案？
- 摘要是否直接出現在 API、URL、資料庫、日誌、簽章與客戶腳本中？
- 目前演算法、編碼、正規化規則、物件大小與碰撞處理是什麼？
- 用戶端能否理解演算法前綴，是否存在離線、舊版本或第三方映像？
- 遷移目標是增加演算法、替換預設演算法，還是淘汰已不建議演算法？
- 舊摘要需要驗證多久，如何保留稽核、簽章與可追溯性？
30 秒回答框架
「內容定址把正規化後的位元組摘要作為穩定 ID，便於去重、快取與完整性校驗，但它不證明來源、權限或可用性。我會先把演算法與編碼寫進摘要格式，保留舊摘要到新摘要的索引和可讀別名，再讓新用戶端優先使用新演算法，舊用戶端繼續讀取舊位址。遷移期間雙寫或按需計算新摘要，簽章同時涵蓋演算法、摘要與上下文；所有消費方重新驗證大小與摘要。用命中率、重算成本、用戶端錯誤、簽章驗證與回滾演練作為退出門檻。」
分步驟深入解答
第一步：定義穩定的內容位元組
先明確摘要輸入是原始位元組還是正規化表示。壓縮層、換行、JSON 欄位順序或中繼資料改變都會產生不同摘要；若業務需要語義相同但位元組不同的物件，另設語義版本，不要偷偷正規化導致簽章和稽核失真。
第二步：區分摘要、標籤與簽章
摘要回答「拿到的位元組是否與識別匹配」，標籤回答「使用者想引用哪個版本」，簽章回答「誰在什麼上下文批准了它」。標籤可能移動，摘要通常不可變；簽章應涵蓋演算法、摘要、媒體類型、用途與時間，不能只簽可變標籤。
第三步：說明安全邊界
碰撞、第二原像與原像風險不同；演算法強度也會隨時間變化。摘要驗證不能取代認證、授權、惡意內容掃描或可用性保證。來自不可信來源的內容應先檢查大小與格式，再計算摘要，避免在巨大或惡意輸入上做昂貴處理。
第四步：設計雙演算法物件模型
讓摘要包含演算法前綴與編碼，內部索引支援一個物件對應多個摘要。保留主物件 ID、舊摘要、新摘要、大小、媒體類型與產生時間；API 能力宣告決定預設回傳哪種摘要，但用戶端不能把未知演算法靜默當成舊演算法。
第五步：規劃遷移路徑
先讓讀取端理解新格式，再讓寫入端產生新摘要；舊摘要可透過索引查找同一物件。對熱門物件預先重算，對冷門物件按讀取懶載入，記錄失敗與佇列。新用戶端優先新摘要，舊用戶端透過別名或內容協商繼續工作，不能在同一位址回傳不同位元組。
第六步：處理快取、簽章與供應鏈
快取鍵、CDN、映像清單、SBOM、簽章與稽核事件都要能攜帶演算法前綴。簽章驗證必須檢查摘要、演算法、上下文與憑證信任；遷移期間可以保留雙簽章，但要明確哪一套是發布門檻。映像拉取先核對摘要再解壓或執行。
第七步：控制垃圾回收與回滾
只有舊、新摘要與所有別名都沒有引用時才能回收物件。遷移索引、重算佇列與簽章狀態要可恢復；若新演算法實作出現錯誤，暫停新寫入並回到舊預設，但保留已產生的新摘要與映射。回滾不能刪除仍需驗證的歷史簽章。
第八步：用指標證明遷移完成
監控雙摘要覆蓋率、讀取命中率、重算吞吐、大小不匹配、未知演算法錯誤、簽章失敗、快取命中與回滾次數。按用戶端版本與物件類型分層，設定停止線。舊摘要流量低於閾值且稽核、簽章與第三方驗證完成後，才停止新寫入舊演算法。
設計取捨與邊界
一個物件多個摘要
多摘要提高遷移相容性，卻增加索引、簽章與快取複雜度。把摘要作為可列舉屬性而不是互相覆蓋，明確哪個是預設顯示、哪個用於驗證。
預先計算與按需計算
預先計算降低首次讀取延遲，但消耗大量 CPU 與儲存頻寬；按需計算節省冷資料成本，卻可能造成尾延遲。按熱度、大小與用戶端期限分層，並允許暫停佇列。
摘要驗證與來源認證
摘要可驗證位元組未被改變，不能證明發布者身分。供應鏈需要簽章、透明日誌或可信分發；權限系統仍決定誰能讀取、推送或刪除物件。
失敗演練與演進計畫
用戶端拒絕帶演算法前綴的摘要
提供版本化 API、別名與相容欄位，記錄拒絕率。不能把新摘要截斷成舊格式，也不能讓用戶端猜測演算法。
重算後物件位元組發生變化
凍結輸入版本，比較大小、媒體類型與校驗值，定位壓縮或正規化差異。新摘要必須指向確定位元組；若語義相同但位元組不同，建立新物件版本。
新摘要簽章驗證失敗
檢查簽章上下文、憑證鏈、演算法策略與時鐘，再按版本回退讀取。保留舊簽章驗證能力，禁止為恢復發布而跳過簽章檢查。
常見誤區與追問
誤區一：把摘要當成存取控制
追問：知道摘要的人能否讀取物件？候選人應區分不可猜測、驗證、授權與加密。
誤區二：把標籤當成不可變 ID
追問：標籤移動或回滾時快取和簽章怎麼辦？應使用摘要鎖定內容，簽章涵蓋上下文。
誤區三：遷移只改資料庫欄位
追問：API、映像清單、CDN、用戶端、簽章、日誌與垃圾回收如何同步？
誤區四：只測摘要計算速度
追問：如何驗證大小不匹配、未知演算法、尾延遲、簽章失敗與第三方相容？
延伸追問與參考答案
為什麼 OCI 還記錄物件大小？
大小可在雜湊前拒絕明顯異常輸入，也幫助用戶端預估下載與資源消耗。它不是完整性證明，仍需對最終位元組重新計算摘要。
遷移期間能否讓一個 URL 同時代表兩個摘要？
同一 URL 必須穩定回傳同一位元組與語義。可以讓一個邏輯別名解析到不可變摘要，或在 API 回傳多個明確摘要欄位，但不能按用戶端隨機回傳不同內容。
什麼時候可以停止舊演算法？
新用戶端覆蓋、雙摘要映射、簽章驗證、快取、第三方拉取與稽核指標都達標，且舊摘要流量低於退出閾值後，先停止產生舊摘要，再經過驗證窗口撤銷舊寫入。歷史讀取與簽章驗證按保留期限繼續支援。