应避免使用接口定义常量，因其破坏封装、污染命名空间；推荐用final工具类、枚举或@ConfigurationProperties管理常量，并遵守全大写下划线命名及不可变性规范。
Java 接口中定义常量本身是合法语法，但长期被当作“常量接口”（Constant Interface）使用，属于典型的不良实践。它破坏封装、污染命名空间、误导继承语义，且现代 Java 完全有更清晰、更安全的替代方式。
避免把接口当常量容器用
反例：定义一个空接口只放 public static final 字段，再让类 implements 它来“复用常量”：
❌ 不推荐interface Constants {
int MAX_RETRY = 3;
String DEFAULT_CODE = "OK";
}
class Service implements Constants { // 仅为了用常量而实现接口
void doWork() { System.out.println(MAX_RETRY); }
}
问题在于：
– 实现接口本应表达“能做什么”（行为契约），而非“拥有什么值”；
– 类一旦 implements，其 API 文档和 IDE 提示会错误暴露这些常量为“能力”；
– 若多个常量接口被实现，容易引发字段名冲突或语义混淆。
改用 public static final 类替代
正例：将常量统一放在工具类中，用 final 修饰，并禁止实例化：
在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。
final class ApiConstants {
private ApiConstants() {} // 防止实例化
public static final int MAX_RETRY = 3;
public static final String DEFAULT_CODE = "OK";
public static final String FINAL_STATIC_NAME = "123"; // 全大写+下划线
优势：
– 明确意图：这是常量集合，不是契约；
– 可控访问：通过 ApiConstants.MAX_RETRY 引用，语义清晰；
– 便于分组：按业务域拆分为 DbConstants、HttpConstants 等，不混杂；
– 符合 Effective Java 建议：“包级私有工具类 + 静态常量”比“公有接口”更合理。
优先考虑枚举或配置类管理业务常量
对有含义、需校验、可能扩展的常量（如状态码、类型标识），枚举更安全：
立即学习“Java免费学习笔记（深入）”；
enum OrderStatus {
CREATED("001"), PAID("002"), SHIPPED("003");
private final String code;
OrderStatus(String code) { this.code = code; }
public String getCode() { return code; }
}
或结合 Spring 的 @ConfigurationProperties 管理外部化常量（如超时时间、开关），避免硬编码。
注意命名与不可变性细节
无论放在类还是枚举中，都要遵守：
– 常量名全部大写，单词间用下划线分隔（如 FINAL_STATIC_NAME）；
– 引用的对象必须不可变（如 static final List 应用 Collections.unmodifiableList 包装）；
– 避免 public 非 final 字段，防止子类篡改；
– 不要让常量类继承或被继承——它只是数据载体，不是类型体系一环。
