发布开关是什么
为一次发布而设的开关：功能随代码合入但默认关闭，按放量阶梯逐步打开，全量稳定后退役。管好命名、归属与到期时间，避免开关沉积成永久分支：每个开关都要有人负责、有用途说明、有退役日期，定期巡检清理，否则测试矩阵与代码复杂度会同步上涨，谁也不敢删。
基本信息
| 创建时机 | 随功能合入，默认关闭 |
|---|---|
| 打开时机 | 按放量阶梯逐步打开 |
| 退役 | 全量稳定后删除开关与旧分支代码 |
| 台账 | 记录负责人、用途、到期日，定期巡检 |
| 默认值 | 关闭是安全默认，异常回退依赖它 |
典型使用场景
- 暗发布：合并即部署，全量后才对用户可见。
- 灰度放量：按用户比例或名单逐步打开。
- 故障止血：异常时关开关而非回滚制品。
- AB 验证：两组用户不同行为对比。
- 白名单试用：内部账号先行体验新功能。
开关示意
开关示意
if (flags.newCheckout(user)) {
newCheckout();
} else {
legacyCheckout();
}开关类型
| 类型 | 生命周期 | 例子 |
|---|---|---|
| 发布开关 | 短期、有退役日 | 新结算流程 |
| 实验开关 | 实验结束即回收 | 推荐算法分组 |
| 运维开关 | 长期、应急用 | 降级与限流 |
发布开关是短期的，与实验开关、运维开关的保留策略不同：发布开关应有明确退役点。
默认值语义：关闭是安全默认，回退动作要能在没有新发布的情况下立即生效。
开关判定点要集中：散落在各处的读取会让「关闭」动作遗漏某处。
放量阶梯要预设：百分之一、一成、一半、全量，每档停留多久看什么指标，执行时不用临时拍板。
清理动作并入常规迭代：把开关退役排进版本计划，而不是等有空再清理。
开关变更留痕迹：谁在什么时候打开了什么开关，操作日志与台账要能对上。