Java中应避免使用常量接口，因其破坏封装、引发命名冲突且被JDK废弃；推荐用final类（配private构造器）或enum定义常量，并依作用域合理规划包名与模块可见性。
Java里别用常量接口（interface定义常量），直接用public static final类更安全、更清晰。
为什么常量接口是反模式
常量接口（比如interface Constants { String DB_URL = "..."; }）看似省事，但会让实现类“不自觉地”继承一堆无关的静态字段，破坏封装，还容易引发命名冲突。JDK 自己都废弃了这种用法——java.awt.Font曾有常量接口，后来全删了。
- 实现类一旦
implements Constants，就强制暴露所有常量，IDE 会把它们列在自动补全里，干扰真实 API - 子类无法覆盖或屏蔽这些字段，哪怕只是想隐藏某个过时配置
- 字节码层面，每个实现类都会复制一份字段引用，增加类大小，对热加载或模块化（JPMS）也不友好
该用哪种常量类：final class 还是 enum
看用途选：纯配置值用final class，有限且语义明确的选项用enum。
-
final class ConfigConstants：适合数据库名、超时毫秒数、HTTP头名称等，必须private构造器 +public static final字段 -
enum Status：适合状态码、协议版本、环境类型（DEV/PROD），天然不可变、可遍历、支持switch，还能加方法 - 避免
public class（没final）或public构造器（能被实例化）
示例：
public final class ApiConstants {
private ApiConstants() {} // 防止实例化
public static final int TIMEOUT_MS = 5000;
public static final String AUTH_HEADER = "X-Auth-Token";
}
包路径和模块可见性怎么设
常量类的包名要反映它的作用域，模块化项目里还得配module-info.java导出。
立即学习“Java免费学习笔记（深入）”；
- 项目级通用常量 → 放
com.example.common，用requires声明依赖 - 模块内私有常量 → 包名用
com.example.service.internal，不exports，外部类拿不到 - Spring Boot 项目慎用
@ConfigurationProperties代替硬编码常量，尤其涉及密码、密钥时，应走配置中心或环境变量
IDE 和编译器不会提醒的坑
这些错误不会报红，但上线后可能出问题：
- 用
String常量拼接路径（如ROOT_PATH + "/api"），如果ROOT_PATH末尾已有/，结果变成//api，HTTP客户端可能静默失败 - 数值型常量写成
int却用于需要long的场景（如TimeUnit.SECONDS.toMillis(30)传int没问题，但30 * 1000可能溢出） - 在
static final字段里调用System.getProperty()，会导致类加载时阻塞或读到空值——这类动态值不该进常量类
真正难处理的是跨服务的常量同步，比如订单状态码。这时候别靠 Java 类共享，用数据库字典表或统一枚举服务更靠谱。
