概述
功能开关把“代码进入生产”和“用户看到行为”解耦。这种解耦正是价值所在:在关闭状态下部署,可以先确认代码能启动、能承载流量、能上报指标,再让用户依赖它。回滚也变成一次配置变更,而不是重新部署。如果开关一直不删除,收益就会消失,因为代码中会积累大量指向产品中已无法找到的功能的分支。
步骤
- 在代码评审中声明开关的负责人与到期时间:
const flags = {
'checkout.new-summary': {
owner: 'checkout-team',
expires: '2026-12-01',
defaultValue: false,
},
};
- 先对内部用户开放,再按小比例放量:
await flags.set('checkout.new-summary', {
percentage: 5,
audience: 'internal',
});
- 通过调整曝光比例完成放量或回滚,无需重新部署:
curl -fsS -X PATCH https://flags.example.com/api/flags/checkout.new-summary \
-H 'Content-Type: application/json' -d '{"percentage":100}'
- 全量后删除开关与死分支:
grep -rn 'checkout.new-summary' src/ | wc -l
验证
每一步都应比较两个变体的错误率、延迟与业务指标,只有对比稳定时才扩大曝光。开关服务不可用时应回落到安全默认值,服务仍能启动并正常响应。全量后统计结果应为 0,表示代码、配置与文档中都不再引用该开关,跟踪 issue 也应关闭。
注意事项
- 按比例放量只有在使用稳定标识计算时才保证同一用户看到同一变体。
- 开关评估必须缓存并设置安全默认值,不能阻塞请求。
- 指标需要带上变体维度,否则无法判断新路径是否回退。
- 删除开关应与引入它的 PR 同等优先级,避免死代码长期存在。
- 每月盘点开关清单,过期未清理的应升级为技术债处理。