直接答案：Feature Flag 不是发布成功证明，而是一套可撤回控制
LaunchDarkly 通过环境、SDK 凭据、上下文、目标规则和 rollout 控制不同用户收到的 variation。真正的验收要同时覆盖应用内安全默认值、环境隔离、规则优先级、指标与停止条件、真实回滚和旗标清理。本次 B 级真实增量提供页面专属的发布合同；本站没有接入授权项目，也没有生成任何性能、转化或可靠性测试结果。
环境、项目和所有者先分清
开发、测试与生产环境使用各自规则和凭据，不能用名称相似的环境互相替代。为每个 flag 记录业务所有者、技术所有者、创建原因、影响服务、默认关闭值、最长寿命和清理 issue。生产环境标成关键环境并要求更严格确认只是管理提示，仍要用权限与审批落实。复制规则到新环境后重新检查上下文属性、segment、prerequisite 和默认值，不把测试命中当作生产会相同。
选择正确 SDK 凭据并准备轮换
官方文档区分服务端 SDK key、移动 key 和客户端 ID；服务端 SDK key 应保密，而公开客户端凭据的能力边界也不能被误解为管理权限。密钥只放服务端秘密系统，不进前端、仓库、提示词、截图或回执。按应用和环境隔离凭据，记录所有使用位置。轮换时先创建新密钥、逐个更新并验证连接，再让旧密钥到期或删除；直接删除仍在用的密钥会让评估退回代码 fallback，因此必须演练 fallback 是否安全。
代码 fallback、off variation 和平台关闭不是一回事
SDK 初始化失败或评估异常时，应用使用代码提供的 fallback；flag 关闭时使用配置的 off variation；目标规则未命中时使用 default rule。三者必须分别定义和测试。支付、权限、数据迁移等高风险能力通常应 fail closed，而只影响外观的功能可选择稳定旧版本。不要假定后台点击 Off 就必然恢复：代码可能绕过 flag、缓存尚未更新、旧客户端离线或新数据结构已经不兼容。
目标规则按优先级和真实上下文验收
规则由上下文种类、属性、运算符和值组成，并按顺序评估。上线前用包含、排除、缺字段、空值、大小写、数组、多 context 和跨租户样本测试；敏感属性不应为方便 targeting 而上传。逐条记录为何某个样本收到某 variation，避免规则重叠让前面的宽条件遮蔽后面的限制。segment、prerequisite 或属性模式变化时，重新运行样本矩阵。
灰度扩大必须有指标、窗口和停止条件
百分比 rollout 说明哪些 context 接收 variation，不等于随机实验结论。先确定 randomization unit、关键业务与技术指标、基线、观察窗口、数据延迟、最小样本和异常停止阈值；每次只扩大到下一阶段并保留批准回执。错误率、延迟和资源使用用于运行安全，转化或满意度需要独立分析。没有取到真实指标时只能写“未取数”，不能因为没有报警就判断新版本更好。
回滚要验证应用状态与外部副作用
官方将 flag toggle 描述为功能的 circuit breaker，并提供恢复近期目标配置的能力。实际回滚需确认配置传播、SDK 缓存、客户端版本、数据库写入、队列、搜索索引、邮件和第三方调用。对不可逆迁移使用双写、兼容读或单独 kill switch，不能依赖一个 UI 开关。演练时从一小批受控 context 触发异常，执行关闭或恢复旧规则，再读回应用结果和副作用，记录恢复时长与残留。
审批、API Token 与 Agent 自动化边界
管理 API token 与 SDK 凭据用途不同。自动化只取得需要的项目、环境和动作权限，生产变更要求审批、变更摘要和期望版本；模型可以生成候选规则或发布说明，但不能持有宽权限 token 自主扩大比例。服务端校验 flag key、环境、variation、目标范围、阶段与最大权重，并拒绝未知 segment 和跨项目操作。所有写入带幂等和审计，失败重试先读当前版本，避免覆盖人工变更。
旗标债务要有到期和删除证据
功能稳定后，永久 flag 会增加分支、测试组合和事故判断成本。按类型设置到期：发布 flag 在全量稳定后删除旧分支，运营 flag 保留明确所有者与长期测试，kill switch 定期演练。删除顺序先确认所有客户端版本不再依赖，再移除目标规则和 SDK 评估代码，最后删除平台 flag 与旧凭据。保留清理 PR、发布记录和搜索结果，防止同名 flag 被误认为旧对象继续使用。
渐进式发布停止后，用户分桶可能发生变化
LaunchDarkly 当前文档说明，渐进式发布按 context 分桶并随时间扩大；停止后创建新的渐进式或 guarded rollout，可能把 variation 分配给不同的一组 context，而普通 percentage rollout 在规则和 context kind 不变时保持分桶。小样本下实际数量也可能与百分比有明显偏差。因此发布合同不能只写“从 5% 升到 25%”：还要固定 environment、flag key、context kind、bucket 属性、每步持续时间、最小样本、观察指标、停止条件与停止后要服务的明确 variation。
把默认规则、off variation 和代码 fallback 分开验收
默认规则用于没有命中前序规则的 context；off variation 用于旗标关闭后；代码 fallback 用于 SDK 尚未初始化、旗标不存在或无法取得状态等情况。三者可能不同，必须分别用测试 context 和断网启动验证。回滚时先确认控制台保存成功，再从客户端或服务端 SDK 读回 variation，并检查外部写入、缓存和数据库迁移是否需要单独恢复。官方当前资料包括 Progressive rollouts、Default rule 和 SDK setup 与 fallback，核验于 2026 年 10 月 12 日。本站未登录客户项目、未运行真实灰度，以上是验收方法。
独立发布验收合同
随文 JSON 示例包含项目环境、flag、fallback、off variation、目标样本、灰度阶段、指标、审批、回滚和清理。离线字段完整不证明真实 LaunchDarkly 配置或业务效果，团队应把实际版本、脱敏截图、日志和负责人写入受控副本。
当前官方来源
- LaunchDarkly：Environments
- LaunchDarkly：SDK credentials
- LaunchDarkly：Targeting rules
- LaunchDarkly：Turning flags on and off
- LaunchDarkly：Restore Previous Flag Version
继续完成相邻任务
需要代码变更验收可阅读提交 PR 前测试、权限与回滚；需要多模型或服务故障降级可阅读API 故障恢复指南；需要保护自动化凭据可阅读智能体密钥保护清单。
核验边界
本文于 2026 年 10 月 5 日核验。界面、凭据类型、rollout、审批、恢复版本、API 与套餐会变化，实施日应重开官方文档并在自己的项目复验。Bing Webmaster、Search Console、排名、展现、点击、CTR、流量、用户、转化和实验结果均未取数。
