Feature Flag 完全指南：分级发布 / 灰度 / A-B test
Feature Flag 是把"功能完成"与"功能上线"解耦的关键基础设施。它让 trunk-based development 成为可能，让灰度发布从手工配置走向自动化，让 A-B 实验成为产品决策的标准武器。但 Feature Flag 也是技术债的最大温床之一：用得好是降本增效的利器，用得差是几年清不完的 if-else 迷宫。本文系统讲解 flag 的四大类型、主流平台选型、内网部署、CI/CD 集成、技术债清理，帮你把 Feature Flag 从"加个开关"升级为成熟的工程能力。
一、为什么需要 Feature Flag
没有 Feature Flag 的世界里，"功能完成"和"功能上线"是同一件事：代码合入 main 就意味着用户立刻看到。这个耦合带来三个严重问题。第一，半成品功能不能合入，必须长期持有 feature 分支，集成成本指数上升。第二，灰度发布只能靠多套环境或多版本部署，运维复杂度高。第三，新功能出问题只能回滚发布，影响整条链路。
Feature Flag 把这三个问题一次性解决：代码可以合入但默认关闭、灰度可以按百分比 / 用户 / 地域细粒度控制、出问题一个 toggle 秒级关闭。这就是为什么 Google、Meta、Netflix、字节都把 Feature Flag 列为基础设施的一等公民。
更深层的价值是产品决策：A-B 实验让"哪种文案转化率高""哪个推荐算法留存好"从主观争论变成数据驱动的实证问题。当一个组织把 Feature Flag 用熟，研发与产品的合作模式会发生根本变化——从"我们觉得这样好"变成"我们做了实验数据显示这样好"。
二、四大类型：release、experiment、ops、permission
第一种是 release flag。生命周期短（几天到几周），目的是把代码上线与功能上线解耦。典型用法：合入 main 时默认 false，部署后逐步从 1%、10%、50% 灰度到 100%，全量后立即从代码中删除。release flag 的关键特征是"必死"，留太久就成了债。
第二种是 experiment flag。生命周期中等（几周到几个月），目的是 A-B 测试不同方案的指标差异。它和 release flag 的最大区别是：实验期内多个分支必须长期共存，结束后选择获胜者并淘汰其他分支。配套需要的是统计显著性框架、分流哈希、指标收集管道。
第三种是 ops flag（也叫 kill switch）。生命周期长（数月到数年），目的是为高风险操作保留紧急熔断能力。例如"是否启用新支付通道""是否启用大查询限流""是否对某地区降级"。ops flag 通常长期保持但默认开启，仅在事故时快速关闭。
第四种是 permission flag。生命周期更长（数年甚至永久），目的是基于用户身份、订阅级别、企业版本控制功能可见性。例如"高级会员才能看的功能""企业版独享的接口"。这种 flag 实际上是产品形态的一部分，不属于技术债范畴。
区分这四种类型是 Feature Flag 治理的第一步。把它们用同一套 SDK 实现没问题，但生命周期管理必须分开。把 experiment flag 当成 release flag 跑，会把实验跑成永久；把 release flag 当成 ops flag 留，会把代码堆成迷宫。
三、主流平台对比
LaunchDarkly 是行业标杆，企业级 SaaS，全球化部署，SDK 覆盖几乎所有语言。优点是稳定性、可观测性、与 Datadog/PagerDuty 集成深度都很高。缺点是价格昂贵（按 MAU 计费），且不支持私有化部署，国内合规场景几乎用不上。适合海外业务、对稳定性要求极高的金融科技公司。
Statsig 是 LaunchDarkly 的强力竞争者，由前 Meta 工程师创立，主打"实验和 flag 一体化"。它的统计分析能力是同类最强的，内建 CUPED 方差缩减、序贯分析等高级实验设计。SDK 性能好、缓存策略激进。同样是 SaaS，国内合规受限。
GrowthBook 是开源（MIT）方案中最成熟的，提供 SaaS 与自部署两种形态。后端用 Postgres / MongoDB，前端 React UI 很现代，统计引擎基于 Bayesian。开源版本就足够中小团队使用，需要更高级特性时升级 SaaS。是国内私有化部署的优选之一。
Unleash 是另一个开源（Apache 2.0）老牌项目，挪威团队维护，Docker 一键启动，配置语义清晰。它没有强 A-B 实验能力，更聚焦于 release 与 ops flag。如果你只需要 flag 不需要实验框架，Unleash 比 GrowthBook 更轻量。
自研也是常见选择。小团队 Redis + 简单的管理后台 + 几行 SDK 代码就能跑通基础场景。但自研的隐藏成本是 SDK 多语言适配、缓存一致性、灰度算法、可观测性，几年后会发现把"不到一周写完"的工具维护成"半个全职工程师"。建议自研只覆盖核心简单场景，复杂功能引入开源平台。需要校验 flag JSON schema 时可以使用JSON 格式化工具。
四、内网部署与中国合规
国内私有化场景的核心约束是数据不出内网、控制面在公司域内。这排除了 LaunchDarkly、Statsig、Optimizely 等纯 SaaS 方案。推荐三种路径。
第一是 Unleash 自部署。Docker Compose 三个容器（API、UI、Postgres）启动，10 分钟跑通基础流程。Unleash 的 SDK 支持 Node、Java、Go、Python、Ruby、PHP，覆盖国内主流后端栈。没有数据出境问题，是稳健的入门选择。
第二是 GrowthBook 自部署。组件比 Unleash 多，但额外提供完整的实验分析平台，对希望"flag + 实验"一体化的团队更合适。GrowthBook 后端可以接 Postgres、MySQL、ClickHouse、BigQuery，与现有数据栈集成灵活。
第三是基于 Apollo / Nacos 的轻改造。如果团队已经在用阿里巴巴的 Apollo 配置中心，可以把它扩展成 flag 平台：每个 flag 是一个配置项，灰度规则用 Apollo 的灰度功能实现，A-B 实验另接埋点系统。优点是零增量基础设施，缺点是 UI 不够 flag 友好、A-B 实验体验差。
无论哪种方案，都建议建立"flag 注册表"内部 Wiki，记录每个 flag 的负责人、用途、生命周期、清理时间。flag 失控的根源往往不是平台不够强，而是治理缺位。
五、CI/CD 集成与自动化
Feature Flag 与 CI/CD 的关系常被低估。最基本的集成是：开发阶段创建 flag、合入 main 时通过 PR 自动注册到 flag 平台、灰度规则随部署变化、新版本完成全量后自动归档。这一整套链路应该用 IaC（基础设施即代码）的方式管理，而不是手动点击 UI。
具体做法是把 flag 配置写成 YAML 或 JSON 文件，纳入 git 仓库，通过 PR 评审任何 flag 变更。flag 平台提供 CLI 或 webhook，git push 触发同步。这样所有 flag 变更都有 git history、有 PR description、有 reviewer 签字，符合 SOX、ISO 27001 等合规要求。
更进一步是自动化的 flag 生命周期管理：每个 release flag 在创建时必须填写 expiry date，到期 7 天前 CI 自动给负责人发通知；过期后 PR 自动加入 flag 清理任务；100% 启用满 14 天自动建 cleanup PR。这套流水线能从根本上抑制 flag 债务积累。需要在配置文件中校验日期格式时可使用时间戳工具。
六、技术债清理：为什么 flag 越来越多
Feature Flag 最大的反模式是"加 flag 容易，删 flag 难"。常见症状包括：flag 数量逐月增长、80% 的 flag 长期 100% 启用、新人看到 if 判断不敢动、code search 一搜满屏 isFlagEnabled。一旦走到这一步，回滚成本极高。
清理策略的核心是机制化：第一，每个 flag 创建时强制填 owner、expiry、purpose；第二，CI 跑 flag scan 工具（LaunchDarkly Code References、Statsig 的 Code Tracker）扫描代码中所有 flag 引用，与平台中的 flag 列表对账，发现孤儿 flag 报警；第三，把 flag 清理纳入团队的常规 sprint，而不是"等不忙了再做"。
技术上清理一个 release flag 的步骤是：确认 100% 启用满 14 天、确认上下游依赖都已迁移、删除所有 if 判断、删除 flag SDK 调用、删除平台中的 flag、合入 main、监控一周。这个流程应该形成一个 PR 模板，让清理动作有标准节奏。
七、A-B 测试的统计基础
真正用好 experiment flag 需要懂一些基础统计。最重要的概念是"显著性"和"功效"。显著性（p-value）回答"观察到的差异是不是偶然"，功效（power）回答"如果差异真的存在我能不能检测出来"。一个负责任的实验需要在跑之前算出最少样本量，避免实验提前结束被随机波动误判。
常见错误包括：peeking（每天看一次结果，看到显著就停）、HARKing（事后挑指标）、忽略多重检验（同时看 10 个指标其中一个 p 小于 0.05 是必然的）。这些错误会让实验结论完全失去意义。Statsig 和 GrowthBook 都内建 sequential testing、CUPED 方差缩减等技术，可以一定程度缓解 peeking 问题。
实验结束后还要做"长期效应分析"：一个新功能短期数据看起来好，可能只是新鲜感；3 个月后留存才是真正的信号。建议核心指标的实验跑足两个完整业务周期，不要为了赶 OKR 提前下结论。需要分析实验数据时可以借助JSON 格式化工具预处理埋点日志。
八、常见陷阱与最佳实践清单
陷阱一：flag 嵌套。一个 flag 内部 if 又判断另一个 flag，三层嵌套后基本无法测试。规则是每个代码路径最多依赖一个 flag，超过就重构。
陷阱二：flag 与配置混用。flag 应该是 boolean 或离散值，不要把它当成"可动态修改的任意配置"。需要复杂配置请用 Apollo / Nacos / Consul。
陷阱三：flag 评估失败导致 5xx。flag SDK 网络抖动是常态，所有 flag 调用必须传 default 参数，default 必须是安全的旧版本，绝不能让 flag 异常打挂业务。
陷阱四：实验和 release 混用。release flag 灰度结束后必删，experiment flag 实验结束后选获胜者。两者基础设施可以共用，但生命周期必须分开管理。
陷阱五：缺少审计。所有 flag 变更都应有 git history 或操作日志，谁、什么时间、改了什么、为什么改。事故复盘时这些数据是黄金。
最佳实践清单：每个 flag 有 owner 与 expiry；release flag 生命周期不超过 90 天；CI 自动扫描代码与平台对账；flag 评估必须有 default 兜底；experiment flag 跑足样本量不提前停；flag 变更走 git PR 评审；至少每季度一次 flag 债务复盘。
常见问题
Feature Flag 和环境变量有什么区别？
环境变量在进程启动时读取一次，改变需要重启服务，无法做到细粒度的用户级、地域级、百分比级控制。Feature Flag 是运行时可改的开关，通常按用户 ID、地区、设备、版本号路由不同分支，无需重启即可灰度。环境变量适合配置层（数据库地址、密钥、域名），Feature Flag 适合产品层（新功能开关、A-B 实验、紧急熔断）。两者是互补关系而非替代。
Feature Flag 会带来技术债吗？怎么清理？
会而且很严重。每个 flag 都是一个 if-else 分支，长期不清理会导致代码路径爆炸、测试覆盖困难、新人难以理解。最佳实践是给每个 release flag 设定生命周期上限（通常 30 到 90 天），到期由 CI 自动报警；定期跑 flag debt 报表统计已 100% 启用的 flag；把清理 flag 当作正常的代码任务安排到 sprint，而不是"以后再说"。LaunchDarkly、Statsig 都内建过期检测。
国内合规与内网部署用什么方案？
国内私有化场景通常排除 LaunchDarkly 这类纯 SaaS。推荐方案有三：自部署 Unleash（开源、Apache 2.0、Docker 一键启动）；GrowthBook 自建版（开源 MIT、Postgres 后端）；自研 + Redis（小团队足够，不要造大轮子）。如果业务在阿里云或腾讯云，也可以用云厂商的配置中心（Apollo、Nacos）改造成 flag 平台。关键是控制面要私有化，数据不出公司内网。
A-B 测试和 release flag 是同一个东西吗？
不是。release flag 关注"是否上线"，按时间线从 0% 灰度到 100%，最终必删；experiment flag 关注"哪个版本好"，需要长期保持多分支并发流量，配合统计显著性分析。两者底层基础设施可以共用一个 SDK，但产品流程、生命周期、读取数据完全不同。混用是常见反模式：把 A-B 实验当 release 跑会失去统计意义，把 release 当 A-B 跑会让 flag 永远清理不掉。
flag 评估失败应该返回什么默认值？
永远返回"安全的旧版本"。如果 flag SDK 网络抖动、配置中心宕机、本地缓存过期，代码必须 graceful degrade 到上线前的稳定路径，绝不能直接抛异常导致 5xx。实践上每个 flag 调用都要传 default 参数，且 default 是经过深思熟虑的安全值。同时关键链路要有本地兜底缓存，flag 服务挂了业务仍能跑。把 flag 系统当成可降级的依赖，而不是强一致的真理之源。