什么是 hardcode（硬编码）？一句话 hardcode 就是把本该可配置、可变化的值直接写死在代码里。

在过去的数十年中，我们开发规范， 不允许 hardcode， 但是很多业务逻辑的使用频率不足 20%， 把这些功能全部用动态实现，即产生开发工作量，得不偿失。

对于低频率的修改，反而我们区代码中改一个字符串，成本更低。

在过去数十年的软件开发实践中，开发规范通常都强调避免 hardcode。但在真实业务中，很多业务逻辑的使用频率并不高，甚至不足 20%。如果为了这些低频功能全部设计成动态配置，不仅会增加开发复杂度，也会带来额外的维护成本，甚至各种配置动态加载和事件监控影响主程序的性能，往往得不偿失。

对于低频变更场景，与其构建一套复杂的动态配置机制，不如直接在代码中修改一个字符串，成本反而更低。

我们都经历过微服务和配置中心，还有印象吗？

当年很多系统为了追求“灵活”和“解耦”，把原本简单的配置不断外置，把原本可以直接写清楚的逻辑拆成分布式配置项。结果系统看似更加灵活，实际却变得更难理解、更难排查，也更难维护。

很多问题不再能通过阅读代码直接定位，而是需要同时查看数据库、配置中心、缓存、环境变量和多个服务之间的调用关系。所谓的“灵活性”，最后变成了认知成本和运维成本。对于高频变化、强运营驱动的场景，动态配置当然有价值；但对于低频变化、规则稳定、影响范围可控的业务逻辑，过度动态化反而是一种工程负担。

一个配置中心里大几十个配置文件，每个配置文件的配置项超过一页A4纸，其中 80% 自它们创建以来就安静地躺在那里从未被修改过。每次升级光是核对配置文件就要花掉一些时间，由于配置产生的故障比比皆是，甚至可以说上线后的验收测试的核心之一就是检查这些配置是否正确。

如今，我们开始主动“去微服务”、不在使用配置中心，清理大量无用配置项。对于低频变更、规则稳定的业务逻辑，更多采用常量配置，让系统回到清晰、可读、可控的状态。

最终带来的结果是：升级链路更短，系统复杂度更低，发布更可控，真正实现了一键升级、秒级完成。

至于大量 hardcode 会不会增加维护成本？在过去答案是有可能。但在 AI 辅助开发时代，低频、明确、局部的规则修改，已经可以交给 AI 完成，几乎是零成本。