别用接口定义常量，应使用final类封装的public static final字段。接口本意是契约而非命名空间，塞入常量会污染API、引发继承污染，且Java 9+模块下访问更麻烦；enum更适合状态类常量，具备类型安全与可扩展性。
Java里该用public static final字段还是接口定义常量
直接说结论：别用接口定义常量，老老实实用public static final字段，配合final类封装。接口常量是Java早期的权宜之计，现在纯属反模式。
原因很简单：接口本意是契约，不是命名空间。把常量塞进接口，会污染实现类的API，还可能引发意外的继承污染——哪怕你没写implements，IDE或重构工具也可能自动加进去。
- 接口中所有字段默认是
public static final，无法控制可见性或初始化时机 - 实现类会“继承”这些字段，导致
MyClass.CONST_A这种调用看起来像自己定义的，实则来自接口 - Java 9+ 模块系统下，接口常量跨模块访问更麻烦，而
public static final类字段可精准控制exports
怎么写一个干净的常量类
核心就三点：类必须final、构造器私有、字段全public static final。不许继承，不许实例化，语义清晰。
示例：
立即学习“Java免费学习笔记（深入）”；
public final class HttpConstants {
private HttpConstants() {} // 防止实例化
public static final int STATUS_OK = 200;
public static final String HEADER_CONTENT_TYPE = "Content-Type";
public static final String METHOD_GET = "GET";
}
- 类名用
Constants后缀，符合直觉；避免叫Const或Defs这种模糊缩写 - 字符串常量优先用
String而非char[]，除非涉及敏感信息（如密码）需手动清空 - 数值常量尽量用具体类型：
long代替Long，避免自动装箱开销 - 不要为了“分组”而嵌套静态类，比如
HttpConstants.Header.XXX——拆成HttpHeaderConstants更易维护
为什么enum比常量类更适合状态/选项类常量
如果常量代表有限、互斥的取值（如HTTP方法、日志级别、订单状态），enum是唯一合理选择。它自带类型安全、不可变、可扩展行为等优势，public static final做不到。
错误写法：
public static final String STATUS_PENDING = "PENDING"; public static final String STATUS_PROCESSING = "PROCESSING";
正确写法：
public enum OrderStatus {
PENDING, PROCESSING, COMPLETED, CANCELLED
}
-
enum实例在类加载时初始化，线程安全；字符串常量靠JVM保证，但拼错就成NullPointerException - 能直接用
switch(OrderStatus.PENDING)，编译期检查；字符串switch只在Java 14+支持，且不校验字面值是否属于常量集 - 后续想给每个状态加描述、颜色、处理逻辑？
enum直接加字段和方法；字符串常量只能另建映射表
容易被忽略的细节：常量内联与热部署问题
Java编译器会对public static final基础类型（int、String等）做编译期内联——也就是说，引用它的代码实际编译后不依赖原类，而是直接嵌入字面值。这会导致热部署或模块更新时行为不一致。
- 比如
VersionConstants.VERSION = "1.2.0"被A模块引用，你只更新VersionConstants类，A模块不会感知变更 - 解决办法：对需要运行时可变的“伪常量”，去掉
final，或改用static方法返回（如Config.getTimeout()） - 字符串常量若含表达式（如
public static final String PATH = "/api/" + VERSION;），不会内联，但可读性差，建议用String.format或构建器
真正难的从来不是“怎么定义”，而是想清楚这个值到底会不会变、变的时候谁该感知、变了之后要不要兼容旧行为——这些决定比语法选择重要得多。
