Spring Boot最佳实践：静态值存properties还是Java类判定方法

不存在强制统一的官方最佳实践，但行业内经过多年项目沉淀，已经有非常清晰的判断逻辑，覆盖绝大多数开发场景。

核心判断准则 #

本质判断逻辑非常简单：修改这个值的时候，是否需要重新走代码编译、测试、打包发版的全流程？不需要走的就放配置文件，必须走的就定义为Java常量。

• 凡是和部署环境强相关、不同环境（开发/测试/生产）取值不同的参数，一律放配置文件
• 凡是需要运维、运营人员在不修改代码的前提下调整的参数，一律放配置文件
• 凡是属于业务逻辑固有规则、修改后必须同步调整代码逻辑才能保证系统正常运行的固定值，一律定义为Java常量
• 不要为了所谓的“灵活性”把所有值都外部化到配置文件，过度配置会大幅降低代码可读性，排查问题时需要反复在代码和配置间跳转，反而提升维护成本

针对你提到的两个典型场景的选型建议 #

1. 业务对象有效性的定时校验间隔 #

绝大多数场景下建议放到application.properties中配置。
定时任务执行间隔属于典型的运维可调参数：上线后可能遇到生产数据量远超预期、原有间隔导致任务堆积的情况，也可能在测试环境需要缩短间隔快速验证逻辑，这类调整完全不需要改动业务代码，直接修改配置重启即可生效，部分场景结合配置中心还可以做到不重启动态调整。
只有一种例外：如果这个间隔是合规要求强绑定的固定规则（比如监管要求必须每15分钟整执行一次校验，偏差超过10秒就不合规），那就直接定义为Java常量，避免被随意修改触发合规风险。

2. 已捕获异常对应的UI错误提示信息 #

按提示的属性拆分处理：

• 固定不变的、和校验逻辑强绑定的基础提示，比如“手机号格式不符合要求”“用户ID不能为空”这类，直接定义为Java常量即可，最好统一收口到专门的错误码常量类中维护，不要散落在各个业务方法里
• 需要随运营需求、合规要求动态调整的提示，比如活动期间的报错要附加活动规则说明、多语言场景下的不同语种文案，建议放到外部配置中（多语言场景可以直接使用Spring Boot原生支持的i18n资源文件，本质也是外部化配置），调整时不需要重新发版。

实际项目中的通用处理惯例 #

• 环境类参数全量进配置：数据库连接信息、第三方服务密钥、日志级别、线程池大小、服务端口、跨域允许的域名列表，全部放在配置文件中，支持按Spring Profile做不同环境的配置覆盖
• 逻辑固定值全量做常量：业务状态枚举值、固定校验规则的阈值（比如密码长度要求、订单号生成规则前缀）、不会变动的正则校验规则、自定义错误码，全部定义为static final类型的Java常量，统一按业务域归类到对应的常量类或枚举类中
• 动态可调参数接入配置中心：比如功能开关、限流阈值、可运营调整的活动规则、动态文案，除了放在配置文件外，生产环境通常会接入配置中心，支持不重启服务实时生效
• 配置项加合理的默认值：对于放在配置文件中的参数，要在代码中设置兜底的默认值，避免配置遗漏导致服务启动失败

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