OpenFeature 評估上下文與 Hooks：面試如何守住 Feature Flag 邊界？

題幹與適用情境

面試官可能會問：「請解釋 OpenFeature 的 evaluation context、provider 和 hooks 如何協作，並說明例外、型別與隱私邊界。」

這題考察你是否理解 OpenFeature 是面向應用、與供應商無關的評估 API，而不是完整的旗標後台或授權系統。規範把 flag key、預設值、評估上下文、provider 和 evaluation details 分開；hooks 可用於驗證、補充上下文、記錄遙測或處理錯誤，但不應悄悄改變業務授權語義。

面試官考察點

能否區分應用呼叫方、provider、evaluation context 和 flag metadata。
能否說明 typed evaluation 與預設值如何共同形成穩定的失敗行為。
能否正確使用 transaction context 與 hooks，而不是依賴全域可變狀態。
能否處理 provider 逾時、型別不匹配、缺失 flag 和隱私資料。
能否將評估日誌、稽核和業務授權邊界分開。

回答前需要釐清的問題

旗標控制的是漸進發布、實驗分流，還是安全授權？
評估需要哪些上下文，哪些欄位不能離開程序或進入日誌？
provider 是本地記憶體、遠端服務、檔案還是多 provider 組合？
provider 失敗時預設值是否安全，是否要區分 fail-open 與 fail-closed？
需要記錄 evaluation details、規則版本和 provider 錯誤到什麼範圍？

30 秒回答架構

可以這樣回答：

OpenFeature 的應用 API 負責按型別請求 flag 值，evaluation context 提供 targetingKey 和請求範圍的資料，provider 執行具體規則，hooks 在評估生命週期中做驗證、上下文增強和遙測。呼叫方必須提供安全預設值，provider 失敗、型別不匹配或 flag 缺失時回傳可診斷的 details，但不能把 hook 當作授權系統。上下文只放必要欄位並做隱私控制；實驗和發布指標可以記錄規則版本，卻不應把個人資訊寫入日誌。

分步深入解答

先拆分評估職責

呼叫方請求一個有型別的值，provider 決定如何解析規則，SDK 負責把結果與預設值、reason、variant 或 error code 組織起來：

text

application -> OpenFeature client -> provider -> flag result
                         |               |
                       hooks        evaluation details

provider 是規則來源和評估實作，不能假設所有 provider 都有相同快取、網路或一致性特徵。呼叫方仍需定義預設值和失敗後的業務動作。

設計 evaluation context

上下文可以包含 targetingKey、使用者或組織屬性，以及由交易傳播的欄位。只傳遞規則真正需要的資料；電子郵件、IP、裝置標識等敏感欄位應雜湊、裁剪或不傳送。交易上下文應隨請求傳播，避免使用跨請求共享的可變全域物件。

使用 typed evaluation 與 details

布林、字串、數字和結構化值分別使用對應 API，並提供型別匹配的預設值。evaluation details 可包含 provider、reason、variant、error code 和 metadata，適合診斷和實驗分析。details 不是業務授權結論，呼叫方需要把「旗標關閉」與「使用者無權存取」分開處理。

安排 hooks 與故障策略

hooks 可在 before、after、error、finally 等階段驗證值、加入遙測、記錄例外或補充上下文。它們必須冪等、低延遲且不洩露原始隱私。遠端 provider 逾時或返回型別錯誤時，使用安全預設值和降級指標；高風險功能可以 fail-closed，但應在題目中說明使用者影響與恢復路徑。

高品質示範回答

我會把 OpenFeature 當作應用評估契約。呼叫方用 typed API 請求 flag，並提供與型別一致的安全預設值；evaluation context 只攜帶規則真正需要的 targetingKey 和屬性。provider 負責從具體旗標系統取得並評估規則，回傳值、reason、variant、error code 和 metadata。hooks 可以在生命週期階段驗證、補充上下文和寫遙測，但不替代授權，也不能隱式改寫結果。遠端 provider 逾時、flag 缺失或型別不匹配時走定義好的預設值，並監控錯誤率和規則版本。日誌只記錄匿名化的 targetingKey、flag key、variant 和版本，不寫電子郵件或完整請求上下文。對發布實驗採用 fail-open 還是 fail-closed 要按風險說明，並演練快取過期、provider 恢復和回滾。

常見錯誤

把 OpenFeature 說成完整的旗標控制台、設定分發或授權服務。
讓 hook 修改 flag 值卻不記錄 reason，導致結果不可解釋。
使用與目標型別不匹配的預設值，或把缺失 flag 當成成功。
把完整使用者物件、電子郵件和 IP 無條件塞進 evaluation context。
provider 失敗時無限重試或沒有明確 fail-open/fail-closed 策略。
把 evaluation details 當成最終的權限判斷。

追問及應對

1. targetingKey 可以使用電子郵件嗎？

只有在規則確實需要且隱私評估允許時才使用；更常見做法是穩定、不可逆的使用者或組織標識。日誌與遠端 provider 還要遵守最小化和保留期限。

2. provider 回傳錯誤時應該怎麼辦？

按風險選擇安全預設值，回傳可診斷的 error code，並記錄降級指標。低風險發布旗標可以暫時保守放行，高風險能力應關閉或進入人工恢復流程，關鍵是策略明確且可演練。

3. hooks 能否實作稽核？

可以作為評估事件的遙測入口，但稽核還需要獨立的完整性、存取控制和保留策略。hook 失敗不能阻塞所有業務評估，除非題目明確把稽核成功設為硬門檻。