Feature Flag 把发布与功能解耦：灰度发布的下一块拼图

发布风险的一半来自「发布=上线」

灰度发布解决的是「新版本代码」的放量问题，但很多风险其实来自「新功能」本身：代码已经全量部署了，功能却只想给 10% 的用户开——这时候重新发版一次，灰度的意义就断了。Feature Flag（功能开关）把「部署」和「上线」拆成两个独立动作：代码随时发，功能按需开。这篇讲我们的落地经验。

一、Feature Flag 的三种典型用法

1. 发布开关（Release Flag）：新功能默认关闭，代码全量部署后按用户/比例逐步放开，出问题秒级关闭而不是回滚发版；

2. 运维开关（Ops Flag）：降级非核心功能（如大促时关掉推荐计算），不动代码就能切换系统形态；

3. 实验开关（Experiment Flag）：A/B 测试用，带分流规则与效果指标。

三种开关的生命周期不同：发布开关存活几周就该删（技术债），实验开关跟随实验周期，运维开关可能长期存在。开关没有清理策略，两年后就是几百个没人敢动的 if。

二、实现要点：配置中心就够了，别急着买平台

Feature Flag 不需要专门的商业平台也能起步：配置中心加一层 SDK 判断就是最小实现。关键工程点：

1. 开关判断必须廉价：SDK 本地缓存配置，读取是内存操作；每次请求都远程拉取的实现在高峰期就是新的瓶颈；

2. 开关要有元数据：创建人、创建时间、用途描述、预期下线时间——没有元数据的开关三个月后就没人敢关；

3. 默认值策略：配置中心不可用时开关的兜底值必须是「安全状态」（新功能默认关、降级开关默认开），这个默认值写死在代码里而不是配置里；

4. 审计与灰度联动：开关变更走审批与操作日志，和发布一样对待——它的事实上就是发布。

三、与灰度发布的配合

Feature Flag 和金丝雀是互补关系：金丝雀控制「代码版本的爆炸半径」，Flag 控制「功能的暴露范围」。典型配合流程：代码带 Flag 全量部署（灰度发布保证部署安全）→ 内部员工开 Flag 冒烟 → 种子用户 10% → 全量 → 观察一周 → 删除 Flag 与死代码。每一步的回滚都是「关开关」，秒级生效。

四、两个常见的坑

- Flag 嵌套地狱：if(flagA) { if(flagB) {...} } 组合爆炸，测试矩阵失控。约束：单个代码路径最多一个活跃 Flag，组合场景用配置组合而不是代码嵌套；

- 长期 Flag 忘删：建立 Flag 的「工单生命周期」——创建时登记预期删除时间，超期自动提醒 owner。我们清理过一批两年前的开关，光 dead code 就删了三千行。

结语

Feature Flag 把发布的两个维度（代码部署与功能暴露）解耦后，发布频率可以继续提高而风险不再叠加。从配置中心的最小实现起步，配好元数据与清理机制，两三周就能把这套能力建起来。