功能开关该不该用：先看它解决的问题是不是你的问题

开关默认值必须是「关」，配置中心挂掉时才不会把未完成的功能放出去

它擅长的是灰度发布；如果你只是紧急关闭故障功能，用现成的东西更省事。

先说结论

开关是「降低发布风险」的工具，不是配置管理，加的时候就要想好怎么删

• 适合：灰度发布
• 不适合：客户级配置
• 学习成本：开关判断放在请求链路里，每次多一次远程调用，QPS 上千时必须加本地缓存兜底
• 最大收益：长期不清理的开关会变成隐性分支，半年后没人敢删，也没人说得清它现在是什么状态
• 最大风险：默认值设成开，配置中心故障时半成品功能直接对外

它到底解决什么

开关默认值必须是「关」，配置中心挂掉时才不会把未完成的功能放出去。

换句话说，它把「灰度发布」这件事从手工变成可重复的流程。这是它真正的价值，而不是功能列表的长度。

什么时候不该用

下面三种情况，用了反而更累：

默认值设成开，配置中心故障时半成品功能直接对外

开关只在代码里加不删，两年后有两百个没人敢动

用随机数做灰度，同一用户刷新几次看到不同结果

和替代方案比

按百分比灰度要保证同一用户命中稳定，靠哈希用户 ID 而不是随机数。

这台工具的关键细节

几个决定长期体验的点：

• 开关判断放在请求链路里，每次多一次远程调用，QPS 上千时必须加本地缓存兜底
• 长期不清理的开关会变成隐性分支，半年后没人敢删，也没人说得清它现在是什么状态
• 按百分比灰度要保证同一用户命中稳定，靠哈希用户 ID 而不是随机数
• 开关和权限是两件事，用开关做权限校验迟早出越权

我的建议

开关是「降低发布风险」的工具，不是配置管理，加的时候就要想好怎么删。

先用两周，跑一个真实的小任务；两周后你还想用它，再谈长期。

还有几处容易忽略的

都是小地方，但出问题时往往就卡在这里。

• 每个开关都该有对应的监控指标，否则不知道它到底开没开

工具是解法，不是身份。