移动应用多版本场景下将feature flag用作kill switch的管理问题

不需要每次使用kill switch后都新建独立toggle，目前行业通用的方案是在feature flag的服务端配置逻辑中，增加应用版本的过滤规则，完美适配你提到的场景：

• 服务端flag配置支持版本区间匹配
  所有feature flag的下发都可以绑定生效的应用版本范围，你提到的场景中，修复完功能A发布1.1版本后，将toggle A的生效规则设置为仅应用版本 ≥ 1.1时返回开启状态，此时1.0版本的客户端请求toggle A时，服务端会统一返回关闭状态，不会触发旧版本的异常问题，1.1及以上版本则能正常使用修复后的功能A，全程不需要修改客户端代码，也不用新建toggle。
• 客户端侧内置默认兜底逻辑
  客户端请求flag超时、或未获取到对应flag的配置时，必须硬编码兜底逻辑，对于kill switch类型的flag，兜底逻辑统一设置为关闭对应功能，避免极端情况（比如服务端故障、网络异常）下异常功能被触发。
• 定期清理冗余flag
  当你确认存在问题的旧版本（比如你的场景里的1.0版本）用户占比已经低到可以忽略时，可以在后续的客户端迭代中直接移除toggle A的判断代码，服务端也可以下线对应的flag配置，避免flag数量无限膨胀。

如果你的业务场景更复杂，比如同一个功能有多次迭代修复，可以使用更灵活的配置规则：

• 支持多组版本+状态的匹配规则：比如1.0版本返回关闭、1.1版本返回开启、1.2版本因为新的问题临时返回关闭、1.3版本修复后重新开启，所有规则只需要在服务端配置即可，不需要新建独立的flag。
• 叠加多维度过滤规则：除了版本维度，还可以搭配用户白名单、地区、应用渠道等维度的过滤规则，出现异常时可以更小范围关停功能，不需要全量关闭。

• 不要复用同一个flag承载完全不同的功能逻辑：如果后续要上线的功能和原功能A的逻辑差异超过30%，建议新建独立的flag，避免规则混乱引发线上事故。
• 不要长期保留已下线的flag：冗余的flag会增加后续维护成本，也容易出现误开启的风险，建议每个迭代都清理一次已经不需要的flag。

内容的提问来源于stack exchange，提问作者Ferra76