interface定义常量是反模式，因其违背接口“定义能力契约”的本意，导致实现类无差别继承静态字段、无法控制访问权限、不能含逻辑；应改用final class或enum。
为什么 interface 里定义常量是反模式
因为接口本意是定义「能力契约」，不是存配置值的地方。Java 允许在 interface 中声明 public static final 字段，但编译器会自动加上这些修饰符，导致所有实现类无差别继承这些字段——这不是复用，是污染。
常见错误现象：MyService 实现了 Constants 接口，结果 IDE 提示「MyService 继承了 27 个无意义的常量字段」；单元测试里修改了 DB_URL，却发现其他模块也悄悄读到了新值（因为静态字段共享，且没做隔离）。
- 所有实现类都会把常量“拖进自己的符号表”，哪怕完全不用
- 无法控制访问权限：
interface里的常量强制public，没法设为package-private - 不能含逻辑：比如带默认值计算、延迟初始化、或根据环境切换的值
用 final class 替代时要注意什么
常量类本质是工具箱，不是对象，所以必须禁止实例化，且明确封装边界。
使用场景：项目级通用配置，比如 HTTP 状态码、文件路径前缀、默认超时毫秒数。
立即学习“Java免费学习笔记（深入）”；
- 类必须用
final修饰，防止被继承 - 构造方法私有：
private Constants() {}，避免 new 出实例 - 字段推荐用
static final，但允许加private或package-private控制可见性 - 如果值依赖启动时加载（如从
application.properties读），就别放这里——该交给@ConfigurationProperties或Config类
示例：
public final class HttpConstants {<br> private HttpConstants() {}<br> public static final int STATUS_OK = 200;<br> public static final String HEADER_AUTH = "Authorization";<br>}
什么时候该选 enum 而不是常量类
当这些值构成一个封闭、有限、有业务语义的集合，并且可能需要附加行为或类型安全校验时，enum 是唯一合理选择。
常见错误现象：用字符串常量表示订单状态（"CREATED", "PAID"），结果传错值不报错，运行时才抛 NullPointerException；或者 switch 时漏写某个状态，编译器不提醒。
-
enum编译期限定取值范围，IDE 支持补全，switch 时能提示遗漏分支 - 可自带方法：
orderStatus.isFinal()比"FINISHED".equals(status)更可靠 - 序列化/反序列化更安全：Jackson 默认支持
enum名称映射，字符串常量容易拼错 - 别为了“看起来简洁”把不同维度的常量塞进同一个
enum（比如把 HTTP 状态码和数据库枚举混在一起）
迁移旧代码时最易忽略的兼容性点
直接删掉 interface Constants 并替换为 class 或 enum，很可能让原有引用编译失败——因为 Java 不允许类直接“继承”接口的静态字段，而原来那些实现类是靠 implements Constants 才拿到字段名的。
正确做法是保留旧接口做过渡，但把它变成空壳，并把字段迁走：
- 新建
AppConstants类或对应enum - 旧
interface Constants里字段删光，只留@Deprecated注释，说明迁移路径 - 所有原实现类去掉
implements Constants，改用AppConstants.STATUS_OK这种显式引用 - 注意：如果用了 Lombok 的
@UtilityClass，它生成的私有构造器可能被某些老版本 JDK 反射调用破坏，建议手写private构造器更可控
复杂点在于，有些框架（比如 MyBatis 的 @SelectProvider）会通过反射读取接口常量，这种得查文档确认是否支持类静态字段——不支持就得绕开，而不是硬改。
