同一个存储，两类数据
功能开关和配置常常由同一个配置服务下发，作为同一个存储里的键值对，甚至由同一批人评审。这种相似只是表面的：开关在运行时选择代码分支，配置值则参数化同一条分支。它们的归属、寿命以及出错后的后果完全不同。
生命周期的差异
配置应与系统同寿：超时、连接池大小、端点、限额。开关则应短暂存在：它用于把部署与发布解耦、做实验，或作为紧急关闭手段。发布开关的终态是被删除，删除它的那个提交属于功能本身，而不是清理工作。
混用会破坏什么
当开关和配置共享命名空间，没人知道哪些键可以安全删除。过期开关不断累积，每一个都会让需要测试的状态翻倍；看起来像开关的配置项一留就是几年，临时开关悄悄变成契约中无人记录的组成部分。
一个有用的分类
发布开关用于未完成功能，应当短期存在；实验开关按流量分组用于度量，归实验负责人所有；运维开关是紧急关闭手段，必须定期演练；权限开关表达授权关系，本来就长期存在，因此应该进入数据模型而不是做成开关。
如何分开管理
例如，把开关放在带负责人、过期时间和求值审计的开关服务里，把配置放在部署配置中并用 schema 校验。按存在时长排序定期评审开关，并把活跃开关数量与服务数量对比：比例上升往往在测试问题爆发之前就能预警。