接口不该放常量，因其违背职责分离原则，导致访问控制失效、编译期内联风险、命名空间污染和工具链支持差；应改用 final 工具类或枚举。
Java 中接口确实可以定义常量（即 public static final 字段），但把接口当作“常量容器”来用，是被官方明确反对的反模式。它表面省事，实则埋下维护隐患、语义混淆和编译风险。
为什么接口不该放常量
接口的核心职责是定义行为契约——“能做什么”，而不是提供数据值——“是什么”。把常量塞进去，本质是职责错位：
- 所有字段自动成为
public static final，无法控制访问粒度，比如你没法声明protected或包私有常量 - 常量值在编译期被内联进调用处：改了
MyInterface.TIMEOUT = 5000，所有引用它的类必须重新编译，否则仍用旧值 - 实现类一旦
implements ConstantsInterface，就强制继承一堆与自身逻辑无关的符号，污染命名空间 - 多个接口含同名常量（如都叫
VERSION）时，实现类引用会歧义，必须写成A.VERSION或B.VERSION，失去简洁性 - ID E 无法跳转到常量定义源码（跳去的是字节码常量池），重构、搜索、文档生成都受影响
正确替代方案：用 final 工具类
专用于存放常量的类，应满足三个基本约束：
- 类声明为
public final，禁止继承，防止语义被篡改 - 构造方法私有，并抛出
UnsupportedOperationException，杜绝实例化可能 - 所有字段显式声明为
public static final，命名全大写下划线（如DB_MAX_CONNECTIONS）
示例：
public final class DbConstants {
private DbConstants() {
throw new UnsupportedOperationException("Utility class");
}
public static final int MAX_CONNECTIONS = 20;
public static final String DEFAULT_SCHEMA = "public";
}
使用时直接 DbConstants.MAX_CONNECTIONS，语义清晰、IDE 友好、修改后仅需重编译该类。
什么情况下该用枚举而非工具类
当常量不只是一个值，还携带行为、类型安全或有限取值语义时，枚举才是更优选择：
- 状态码：
OrderStatus.PAID比StatusConstants.PAID = 2更安全，编译期校验，不会传入非法整数 - 带方法的常量：比如每个枚举项可定义自己的超时时间、日志级别或转换逻辑，无需额外 switch 分支
- 天然支持遍历、序列化、
switch表达式，且命名空间隔离，Role.ADMIN和Status.ACTIVE不会冲突
静态导入要克制，不等于方便就是合理
import static 能简化调用，但滥用会降低可读性：
- 适合高频、无歧义、极简成员：如
Math.PI、Objects.requireNonNull、Assertions.assertTrue - 不适合整包静态导入（如
import static com.example.DbConstants.*），会导致命名污染、难以追踪来源、重构困难 - 建议只对真正高频使用的个别常量或方法做静态导入，其余一律用类名限定
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
