硬编码功能标志是可以的（2025）

# 硬编码功能开关并无不妥 来源：https://code.mendhak.com/hardcode-feature-flags/ 功能开关（或称为开关）常用于控制产品中新功能的可见性。实现方式有多种，但最常被讨论和推广的是使用功能开关管理软件。最简单的做法当然是硬编码，尽管相关讨论最少。 尽管功能开关管理软件*可能*功能强大，但它们也带来了复杂性和风险。围绕它们的营销炒作如此猛烈，以至于承认其必要性不足就像承认技术上的无能。我们已经让自己相信，我们不仅需要几个功能开关，还需要扩展到数千个。不仅如此，我们绝对需要在运行时修改功能，而且必须在没有部署、没有重启、没有缓存刷新、没有数据库迁移、没有代码审查、没有测试的情况下完成，因为业务正处于紧急状态，唯一解决办法是更改首页按钮颜色。 这类系统的能力所对应的唯一开关，应该是那种**红色警报**级别的。从架构角度看，它们不过是更复杂的`if`语句，却需要独立管理进程。通常需要专门的基础设施、托管服务、监控体系以及随之而来的所有责任。 从开发生命周期角度看，它们引入了非确定性行为，使代码更难以理解。长期存在的功能开关，尽管最初意图良好，会导致技术债务使代码库僵化；硬编码开关也存在这种风险，但更容易发现和管理。 从安全角度看，它们是一个隐患，因为攻击或漏洞的攻击面随之扩大。 无论如何，为任何软件系统增加更多动态组件都应经过审慎考量，评估其是否真正必要，以及引入的风险是否值得解决相应问题。 硬编码功能开关消除了许多此类问题；它们简单、可靠且安全。这是最朴素的方式，也正因如此，它们才是最佳方案。 只需从一个简单的JSON文件开始，在应用程序启动时读取它，并用它来控制功能的可见性。及时清理开关，在不再需要时移除它们。如果存在时间过长，就让该功能成为默认行为并移除开关。通过正常的开发流程修改值，经过审查、测试和部署。 对于大多数团队和产品来说，这通常已经足够，并且能持续发挥作用。当团队真正达到需要在运行时大规模修改功能的时候，就像单页应用中的状态管理一样，他们会知道自己确实需要它。 过早优化并非明智之举。这是糟糕的设计、糟糕的工程，只会在技术会议上销售人员询问是否有人使用它们时，带来片刻沾沾自喜的满足感。