不该在接口里定义常量，因为其值会被编译器内联，修改后需全部重新编译；接口是契约而非配置容器，混淆抽象与数据边界；ide无法语义跳转且存在命名冲突风险；应改用final工具类管理常量。
为什么不该在接口里定义常量
Java 接口中定义 public static final 字段（即所谓“接口常量”）是合法语法，但这是个被长期误用的设计惯性。JVM 不会为接口生成实例，但编译器仍会把接口中所有 static final 字段的值直接内联进调用处 —— 这意味着一旦修改接口里的 MAX_RETRY 值，所有依赖该接口的类必须重新编译，否则仍用旧值。
- 接口本质是契约，不是配置容器；把常量塞进去模糊了抽象与数据的边界
- IDE 无法对
MyInterface.CONST做语义跳转到定义处（它跳去的是编译后的字节码常量池） - 如果多个接口定义同名常量（比如都叫
VERSION），实现类同时 implements 它们时不会报错，但引用时会歧义
替代方案：用 final 类 + private 构造器
真正安全、可维护的常量组织方式，是定义一个不可实例化、不可继承的工具类：
public final class Constants {
private Constants() {} // 防止实例化
public static final int MAX_RETRY = 3;
public static final String API_BASE_URL = "https://api.example.com";
}
- 所有字段仍是
public static final，外部访问方式不变：Constants.MAX_RETRY - 类路径清晰，支持 IDE 全局搜索、重构、跳转，且修改后只需重编译该类
- 如果需要分组（如 DB 相关、HTTP 相关），就拆成
DbConstants、HttpConstants，比 “接口继承接口” 更直觉 - 避免使用
enum存纯数值/字符串常量 —— enum 是类型安全的有限集合，不是命名空间
如果 legacy 代码里已有接口常量，怎么平滑迁移
直接删掉接口里的常量并改用 Constants 类，大概率会触发编译错误，但别急着全局替换。先做三件事：
- 确认该接口是否真被用作“类型”（比如有类
implements MyConstantsInterface）—— 如果只是拿来读常量，那它本就不该是接口 - 在原接口里把常量字段标记为
@Deprecated，并在 Javadoc 里写明迁移目标类和字段名 - 用 IDE 的 “Find Usages” 查出所有引用位置，在每处手动替换成
Constants.XXX；不要用 “Replace All”，因为可能有同名变量干扰 - 检查构建脚本（如 Maven 的
compiler-plugin版本），确保没开启-Xlint:dep-ann以外的严格警告，否则@Deprecated字段引用会报错
String 常量要特别注意 intern 行为
如果你在接口或 Constants 类里定义 public static final String TOKEN_PREFIX = "auth:"，JVM 会自动将该字符串放入字符串常量池。这本身没问题，但容易忽略两点：
立即学习“Java免费学习笔记（深入）”；
- 若运行时拼接出相同内容（如
"auth:" + "token"），结果不一定 ==TOKEN_PREFIX，除非显式调用.intern() - 大量定义长字符串常量（比如 SQL 模板）会增加 class 文件体积，并在类加载时占用永久代/元空间
- 更稳妥的做法是把这类非简单标识符的字符串移到
resources/下的 properties 或 YAML 文件中，用ResourceBundle或配置中心加载
接口常量这事，表面是语法选择，实际是设计意图的泄漏。越早把常量从接口里请出去，后续加注释、改值、查来源就越省心。别让编译器替你做决定。
