配置与开关怎么审
配置与功能开关的评审重点是默认值与生命周期：新配置默认关闭还是开启、默认值是否安全（fail-safe）、开关什么时候清理、各环境的取值来源与覆盖顺序是否明确、关闭时的旧路径是否仍然可用。长期不清的开关会变成隐藏分支，让代码的实际行为难以推断。
基本信息
| 默认值原则 | 新开关默认关闭，小流量验证后再逐步放开 |
|---|---|
| 登记内容 | 开关名、负责人、创建日期、预计移除版本 |
| 环境差异 | 各环境的取值来源与覆盖顺序要写清楚 |
| 旧路径 | 开关关闭时旧逻辑是否仍可用、是否仍被测试覆盖 |
逐项看什么
- 新配置项的默认值：默认开启还是关闭，出问题时是否安全。
- 开关命名是否能看出归属与用途，避免出现开关一、开关二这样的名字。
- 开关是否有清理计划：负责人、时间点、移除条件。
- 环境差异：开发、测试、生产的取值来源与覆盖顺序是否明确。
- 开关关闭状态下旧路径是否仍被测试覆盖，避免只有新路径可用。
- 灰度范围是否写明：按用户、按比例还是按环境放量，决定了回滚动作怎么做。
默认值选择与后果
| 默认值 | 后果 |
|---|---|
| 默认开启 | 上线即改变全部用户行为，回滚只能等发版 |
| 默认关闭 | 影响面可控，可灰度放量 |
| 缺省值不一致 | 不同环境行为不同，问题难以复现 |
| 开关无清理 | 形成隐藏分支，组合爆炸难以验证 |
开关登记示例
开关登记示例
# 开关名：enable-new-pricing
# 负责人：定价小组
# 创建时间：本次发布
# 预计移除：灰度完成并稳定两周后
# 关闭时的行为：走原有计价路径，该路径仍有测试覆盖长期不清的功能开关会变成隐藏分支：评审时要求登记清理计划。
配置项默认值一旦开启就影响所有用户：把「先关闭、再灰度、最后默认开启」写进团队约定，能显著降低回滚成本。