GO Feature Flag 启动控制

要解决什么问题

当应用通过启动开关或配置项决定「这次发布是否开启某功能」时，常见的痛点是：规则散落在代码或环境变量里、切换需要重新部署、无法针对特定用户做定向灰度，也缺乏统一的验证手段来确认启动行为是否符合预期。这个技能把发布决策收敛到一个外部控制平面，让启动行为不再依赖人工判断或硬编码。

核心能力与工作方式

技能基于 GO Feature Flag 与 OpenFeature 抽象构建：

• 发布规则与目标定位：在控制平面配置发布规则，按 targetingKey（用户唯一标识）做定向匹配，同一功能可对不同用户呈现不同状态。
• 实验与远程配置：支持把功能开关与实验绑定，并通过远程配置下发非布尔型参数，避免每次调整都走一遍代码发布。
• 启动验证：在应用启动阶段读取标志状态并校验启动行为，防止误配置导致功能在错误的人群中开启。

典型工作流是：先在控制平面维护标志与规则，应用侧通过 OpenFeature 兼容客户端读取评估结果，再依据返回值决定启动路径。中继代理（relay proxy）、SDK 与配置存储是可选组合，具体形态取决于你的环境。

适用边界与注意点

• 必须提供 targetingKey：每个评估请求都要携带唯一的用户标识，缺失会导致定向失效。
• 依赖控制平面可用性：启动阶段会发起远程评估，若中继代理或配置存储不可达，需要明确降级策略，避免启动被阻塞。
• 规则漂移风险：标志与规则由外部平面管理，团队应约定配置变更的评审流程，防止未经确认的改动影响线上行为。
• 不替代发布管道：它解决的是「启动时该看到什么」，而不是版本管理、构建或部署编排本身。