发布开关的清理是什么
发布开关（Feature Flag/Toggle）相关代码是最容易沉积的技术债：全量放量、观察期稳定后，开关判断、旧代码分支、配套配置与看板都应该删掉。放任不管的后果是分支组合爆炸、理解成本上升、旧路径暗中被执行。治理手段三件套：把「删除开关」写进发布流程的完成定义；用 lint 或清单检查长期未清理的开关；度量开关平均存活时长，像看待办一样定期清账。
基本信息
| 清理时机 | 全量放量并稳定一个观察期后 |
|---|---|
| 清理内容 | 开关判断、旧代码分支、配置项、看板 |
| 自动化 | 自定义 lint/清单检查未过期开关 |
| 度量 | 追踪开关平均存活时长 |
典型使用场景
- 发布收尾：功能全量后把清理动作纳入完成定义，不留在「以后再说」。
- 季度技术债治理：批量盘点存活超期的开关，集中清理。
- 新人上手：减少分支与路径数量，降低理解成本。
- 配置中心减负：删除废弃键，避免误用与启动失败。
- 组合测试收敛：减少开关组合数量，测试矩阵可控。
检查项
检查项
[ ] 全量已满且无回退需求
[ ] 旧分支代码与测试已删除
[ ] 配置中心开关项已移除
[ ] 相关告警与看板已下线
# 自动检查: 过期开关进 lint 报告开关类型与寿命
| 类型 | 典型寿命 | 清理时机 |
|---|---|---|
| 发布开关 | 天级到周级 | 全量加观察期后 |
| 实验开关 | 周级 | 实验结论产出后 |
| 运维开关 | 长期保留 | 不清理，需权限与审计 |
把「删除开关」写进发布流程的完成定义，否则它永远排在优先级末尾。
开关命名带上日期或工单号（如 checkout_v2_202603）：扫描工具与人工都能一眼识别过期候选。