C++ 面試：如何在混合編譯器車隊中採用 C++26 Contracts？
題目與場景
一個大型 C++ 程式庫同時使用多種編譯器、標準程式庫版本和建置模式。團隊想用 C++26 Contracts 表達 API 的前置條件與後置條件，但擔心編譯器支援不一致、違規處理影響線上程序，以及舊建置鏈無法升級。請設計一個漸進採用方案，並說明如何驗證和回滾。
面試官考察點
- 能否區分契約表達、測試斷言、例外處理和未定義行為。
- 能否識別標準、編譯器、連結器、執行模式和 ABI 的相容邊界。
- 能否把違規處理、效能開銷和生產安全納入發布設計。
- 能否用小範圍遷移和可觀測證據推進語言特性，而不是一次性改造。
先問清楚的澄清問題
- 當前編譯器、標準程式庫、建置系統和目標平台矩陣是什麼，哪些目標必須繼續支援舊版本？
- 契約主要要保護公共 API、內部模組邊界，還是捕捉資料不變量？違規時希望終止、記錄、除錯暫停還是繼續執行？
- 線上效能預算、例外率、核心服務的回滾方式和符號化能力如何？
- 是否已有斷言、測試、靜態分析和發布門禁，可以作為遷移基線？
30 秒回答示範
我會先把 Contracts 當作介面語義和診斷工具，而不是替代所有測試或例外處理。先按編譯器矩陣確認支援範圍，選擇一個內部程式庫做實驗，分別驗證開啟、關閉和不同違規處理模式的行為。公共標頭先保持相容，舊編譯器透過條件建置或不啟用契約的路徑繼續工作。遷移按風險從內部 API 到關鍵服務，觀察建置成功率、契約違規、延遲和二進位相容；任何線上違規都要有明確的暫停與回滾路徑。
深入拆解
1. 先定義契約解決的問題
前置條件描述呼叫者必須滿足的輸入約束，後置條件描述函式返回時應成立的結果，不變量約束物件狀態。它們幫助介面把假設寫在邊界上，但不能替代業務錯誤處理、模糊輸入的降級邏輯或完整測試。先挑選跨模組、難以從呼叫點推斷的約束，避免把每個內部細節都暴露成契約。
2. 畫出工具鏈與 ABI 邊界
列出編譯器版本、標準程式庫、語言模式、連結器、平台和建置設定，逐一確認解析、程式碼生成、違規處理程式庫和除錯資訊是否可用。公共標頭中的新語法可能讓舊編譯器直接失敗；即使能編譯，不同執行模式也可能產生不同診斷行為。先用能力探測和最小範例驗證，再決定條件編譯邊界。
3. 選擇違規處理策略
違規處理需要和服務風險匹配。開發建置可以中斷並提供呼叫堆疊，測試建置應讓測試明確失敗，生產建置則要根據契約嚴重性選擇安全終止、隔離請求或記錄後繼續。繼續執行不能掩蓋狀態已經不可信的事實；記錄必須包含契約位置、輸入摘要和版本，同時避免洩露敏感資料。
4. 評估語義和副作用
契約表達式應盡量無副作用、可重複計算且不依賴未定義的求值順序。團隊要明確開啟、關閉或不同檢測模式下表達式是否求值，以及違規處理是否改變控制流。不要把會修改狀態、發網路請求或依賴時序的操作放進契約；這些行為應留在實作和測試中。
5. 設計漸進遷移和相容層
從不對外的程式庫、純函式和高價值不變量開始，先在單一編譯器和 CI 目標啟用。公共 API 可以透過版本化標頭、條件建置或巨集封裝保持舊車隊可編譯，但巨集只能處理能力差異，不能隱藏不同的業務語義。每次擴大範圍都記錄覆蓋的函式、支援矩陣和未遷移呼叫者。
6. 用證據決定擴大或回滾
建立遷移前基線：建置時間、二進位大小、關鍵路徑延遲、契約違規率、崩潰率和測試缺陷。灰度期間比較啟用前後同一流量和輸入分布，區分真實輸入問題、程式碼缺陷和工具鏈誤報。若違規集中在高價值路徑、效能超過預算或舊目標無法穩定建置，暫停遷移、關閉新語法路徑並恢復上一版本建置產物。
一份更完整的強回答
我會先盤點編譯器、標準程式庫、語言模式、平台和執行模式，確認 C++26 Contracts 在每個目標上的解析和違規處理能力。採用範圍從內部純函式和明確不變量開始，把契約當作介面文件與診斷層，不替代例外、降級或測試。開發和測試環境允許快速失敗，生產則按風險選擇終止、隔離或安全記錄，並保證敏感資訊不進日誌。公共標頭透過能力探測和條件建置保持舊車隊可編譯。以建置成功率、延遲、二進位變化、違規率和崩潰率做灰度門檻，任何高風險異常都觸發暫停和回滾。
常見失分點
- 把 Contracts 當成斷言、例外或測試的完全替代品。
- 只說「升級到 C++26」，沒有編譯器、標準程式庫、連結器和 ABI 矩陣。
- 忽略不同檢測模式和違規處理對控制流、效能與線上安全的影響。
- 在契約表達式中執行有副作用的操作，導致診斷本身改變程式行為。
- 沒有基線、灰度和回滾，只憑編譯通過就擴大遷移範圍。
追問與延伸
追問一：契約違規後應該拋例外嗎？
不能一概而論。契約違規表示程式狀態或呼叫約定已被破壞，是否拋例外要看服務能否安全恢復、例外是否會跨 ABI 邊界，以及團隊的錯誤處理策略。對不可恢復狀態，繼續執行或普通例外都可能掩蓋更嚴重問題。
追問二：如何處理舊編譯器？
先確認公共標頭是否必須被舊編譯器解析。可以用能力探測、條件建置或相容巨集讓舊目標走無契約路徑，但要保留等價測試和文件，避免新舊路徑的業務語義分叉。
追問三：契約會不會拖慢線上服務？
測量而非猜測。比較不同檢測模式、編譯最佳化和輸入分布下的 CPU、延遲和二進位變化；高成本檢查可限制在開發、測試或低比例灰度，同時保留關鍵不變量的低成本監控。
追問四：如何讓團隊避免濫用契約？
建立規則：只表達可驗證的不變量和邊界假設，禁止副作用，說明違規處理和敏感資料要求，並在程式碼審查中檢查。每個契約都應有對應測試、負責人和刪除或調整條件。