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 失败不能阻塞所有业务评价，除非题目明确把审计成功设为硬门槛。