Java中不应在接口中定义全局静态常量，因其违背接口“定义行为契约”的本意；应改用final类（如AppConstants）或外部配置文件+配置类来管理常量。
Java中不能在接口里定义“全局静态常量配置”——这不是接口的设计本意，但很多人误用接口来集中定义public static final字段，形成所谓的“常量接口”。这种写法虽能编译通过，却违背面向对象原则，已被官方明确不推荐。下面讲清楚怎么正确管理常量配置。
为什么“常量接口”是反模式？
接口本应描述“能做什么”（行为契约），而非“是什么值”（数据定义）。把常量塞进接口会导致：
- 实现类被迫继承无关的常量，污染命名空间（比如
MyService implements Constants） - 一旦常量变更，所有实现类都要重新编译
- IDE无法区分哪些字段是业务逻辑所需，哪些只是“凑数”的配置值
- Java 9+ 模块系统下，常量接口可能引发模块可见性问题
推荐方案：用 final 类替代接口
定义一个不可实例化、无继承关系的工具类，专用于存放配置常量：
public final class AppConstants {
private AppConstants() {} // 禁止实例化
<pre class="brush:php;toolbar:false;">public static final int MAX_RETRY_TIMES = 3;
public static final String DEFAULT_CHARSET = "UTF-8";
public static final long SESSION_TIMEOUT_MS = 30 * 60 * 1000L;}
立即学习“Java免费学习笔记（深入）”；
使用时直接通过类名引用：AppConstants.MAX_RETRY_TIMES。语义清晰、安全可控，且符合 Java 编码规范。
更灵活的配置方式：属性文件 + 配置类
真正需要“全局可配”的常量（如数据库地址、超时时间），应从代码中解耦：
- 将值写入
application.properties或config.yml - 用
@ConfigurationProperties（Spring）或java.util.Properties加载 - 封装为不可变配置类，运行时注入
例如 Spring Boot 中：
@ConfigurationProperties(prefix = "app")
public class AppConfig {
private int maxRetryTimes = 3;
private String defaultCharset = "UTF-8";
// getter/setter
}这样修改配置无需改代码、可环境差异化、支持类型安全校验。
小结：别用接口存常量
接口不是配置容器。该用final类就用final类，该用外部配置就用外部配置。保持接口专注契约，让常量各归其位——代码才容易维护、测试和演进。
