快速结论：LaunchDarkly 的核心不是“远程开关”，而是把代码部署与功能发布拆开：应用把 flag key、context 和 fallback 交给 SDK，SDK 按当前环境的 targeting 规则返回 variation。要在生产环境安全使用，必须同时设计 fallback、灰度指标、回滚阈值、context 数据边界和临时旗标清理责任。
本文面向准备接入或正在治理 Feature Flag 的中文开发、SRE 与产品团队。内容依据 LaunchDarkly 官方文档于 2026 年 8 月 13 日复核；套餐权限、控制台界面和 SDK 版本会变化，实施前仍应查看相应 SDK 与账户中的当前说明。
LaunchDarkly 是什么，解决的不是哪类问题
LaunchDarkly 是 Feature Management 平台。代码可以先部署到生产环境，再通过旗标决定某个用户、组织、设备、服务或其他 context 收到哪个 variation。这样能缩小发布爆炸半径，也能让回滚不必等待重新构建和部署。
它不替代代码测试、监控、容量规划或权限治理。如果团队没有可靠指标、没有异常 fallback，或没人清理临时旗标，那么增加平台只会把风险从部署脚本转移到控制台。准备评估其他实验方案时，可对照站内的 Optimizely 功能实验指南；需要把功能发布纳入组织流程时，可继续查看 企业 AI 采用与治理专题。
一次旗标评估到底发生了什么
根据官方 Flag variation evaluation 文档，应用调用 SDK 时至少提供旗标 key、当前 context 与 fallback。SDK 先检查连接、认证、key 和 context，再按 prerequisite、单独定向、规则、segment、百分比分流与默认规则的顺序得到 variation。
客户端、服务端与边缘 SDK 的评估位置不同。官方 SDK 类型说明指出，服务端 SDK 通常使用本地缓存的规则集在进程内评估；客户端 SDK 面向单个终端 context，由 LaunchDarkly 服务完成规则评估。无论哪种方式，业务代码最终只得到 variation，并负责把它转换成实际行为。
| 检查点 | 必须明确 | 失败时怎么办 |
|---|---|---|
| flag key | 跨环境保持稳定，不把显示名称当 key | 记录配置错误并返回 fallback |
| context | 只传 targeting 真正需要的属性 | 缺少属性时不要假定会从后台补齐 |
| variation | 每个值对应的业务行为可被单独测试 | on、off、fallback 三条路径都进入测试 |
| prerequisite | 依赖旗标关闭时的结果已经设计 | 避免依赖链造成不可解释的级联关闭 |
从创建旗标到生产放量的完整步骤
1. 先定义临时还是永久
官方 Creating flags 指南把旗标分为 temporary 与 permanent。用于发布、实验或一次性迁移的旗标通常应是临时的，并在全量稳定后删除代码分支和平台配置；长期作为 kill switch、运营配置或权限能力存在的旗标，才更接近永久旗标。创建时就写 owner、到期日期和清理工单，比上线后再补更可靠。
2. 选择正确 SDK，并在代码里写 fallback
服务端决策、敏感规则和核心授权通常更适合服务端 SDK；只影响界面展示的终端体验才考虑客户端 SDK。fallback 不是随便填的默认值，而是 LaunchDarkly 不可达、认证失败、key 不存在或 context 无效时的业务保底。安全相关功能不能只靠客户端旗标保护。
3. 小范围定向，验证规则顺序
先用内部账号、测试组织或低比例 context 验证。单独定向与规则可能优先于默认百分比分流；只看“默认规则 10%”不足以解释某个用户为什么得到某个 variation。排错时要记录环境、flag key、context kind、命中规则和 evaluation reason，而不是直接改规则碰运气。
4. 用指标决定是否继续放量
官方 Releasing features 文档区分人工、渐进与 guarded rollout。渐进发布按时间提高比例；guarded rollout 还会监控所选指标，并可在检测到回退时通知或自动回滚。它不是所有账户、旗标类型与并行实验都无条件可用，必须在当前计划和旗标配置里核验。
5. 全量不等于结束
全量后仍要观察完整业务周期，确认旧代码路径、数据库迁移和异步任务不再依赖旧 variation。临时旗标达到退出条件后，应删除旗标、死代码和不再需要的指标；否则旗标数量会变成新的技术债。相关的变更审批、故障复盘与权限边界可纳入 AI 安全与治理专题的通用检查框架。
Guarded rollout 自动回滚有哪些边界
官方 Creating guarded rollouts 文档说明，guarded rollout 需要选择监控指标与阶段，可以为指标启用 automatic rollback。系统也会检查样本比例不匹配、样本不足等健康问题。自动回滚只恢复本次受管规则的 variation，不会自动撤销数据库迁移、外部消息、缓存污染或其他不可逆副作用。
| 情形 | 平台可帮助 | 团队仍须负责 |
|---|---|---|
| 错误率或延迟回退 | 按已配置指标通知、暂停或回滚 | 指标质量、阈值、观察窗与根因排查 |
| 样本比例异常 | 进行健康检查并提示风险 | 检查 targeting、埋点和 context 稳定性 |
| 数据库已写入 | 停止继续放量 | 设计兼容迁移与数据补偿 |
| 第三方消息已发送 | 关闭后续新流量 | 处理已发生的外部副作用 |
Context 数据与隐私怎么控制
LaunchDarkly 的 最终用户数据最小化指南说明，SDK 会按配置把用于定向的 context 属性提供给平台。后台 Contexts 列表不会自动替你补齐评估属性；每次评估仍以应用传入的 context 为准。团队应优先使用稳定、非敏感的内部标识，只传规则所需属性，并评估客户端 SDK 的传输与认证方式。
- 不要把密码、令牌、完整支付信息或医疗隐私直接放进 context。
- 把姓名、邮箱等属性设为私有前，先核对相应 SDK 的 private attributes 配置。
- 客户端规则不能承担真正的授权控制；后端仍要做权限校验。
- 跨区域、监管行业或数据驻留场景应先完成法务与安全评审。
上线前可以直接使用的验收清单
| 阶段 | 通过条件 | 证据 |
|---|---|---|
| 设计 | owner、临时/永久、到期与 off 行为明确 | 设计单与清理工单 |
| 代码 | on、off、fallback 与 prerequisite 均测试 | 自动化测试记录 |
| 数据 | context 属性最小化且不承担授权 | 数据字段清单与隐私评审 |
| 发布 | 小流量、指标、阈值、观察窗与审批完成 | 发布计划与监控面板 |
| 回滚 | 关闭旗标后系统仍兼容，副作用有补偿 | 故障演练与回滚记录 |
| 清理 | 临时旗标、死代码和无用指标按期删除 | 代码变更与审计日志 |
LaunchDarkly 适合谁，不适合谁
如果团队频繁发布、需要多环境定向、逐步放量、审批审计和快速关闭能力，LaunchDarkly 值得进入选型。若应用简单、发布极少、没有定向需求，或团队无法承担旗标生命周期治理，先用现有配置系统和可靠部署回滚可能更合适。需要把旗标与模型、API 或 Agent 变更结合时，可继续参考 模型与 API 专题和 AI Agent 与自动化专题。
常见问题
关闭旗标就等于回滚部署吗？
不等于。关闭旗标通常只改变 variation；已经部署的代码、数据库迁移和外部副作用仍存在。部署回滚与功能回滚要分别设计。
百分比从 10% 调到 20%，原用户一定保持不变吗？
不能只凭比例推断。需要保持 flag key、context kind 与稳定 key 一致，并检查规则顺序和分桶配置；更改这些条件可能改变用户命中的 variation。
LaunchDarkly 断网会怎样？
SDK 会按自身缓存与错误处理机制工作，最终仍可能返回代码定义的 fallback。生产验收必须模拟不可达、认证错误与不存在 key，而不是只测试控制台开关。
能用客户端旗标控制付费权限吗？
不能把它作为唯一授权边界。客户端结果可用于界面展示，但服务端仍必须验证真实权限，避免用户伪造或重放客户端状态。
下一步：选择一个可逆、低风险功能做金丝雀：先写 fallback 与回滚阈值，再接 SDK、只开放给内部 context，观察一个完整业务周期，最后决定扩大、暂停或删除旗标。
