接口中定义常量是反模式，因其混淆职责、破坏封装、引发维护隐患；应改用配置类、枚举或配置文件等更清晰可控的方式。
Java 接口中可以定义常量，但这种用法早已被主流开发实践视为“反模式”。它表面上简洁，实则混淆职责、破坏封装、引发维护隐患。真正该做的是把常量归入专门的类或枚举，接口只专注契约定义。
接口中定义常量的语法（不推荐）
Java 允许在接口里声明字段，且默认是 public static final 的，所以以下写法合法但危险：
interface Config {
String API_BASE_URL = "https://api.example.com";
int TIMEOUT_MS = 5000;
boolean ENABLE_RETRY = true;
}
任何实现该接口的类会自动继承这些字段——这不是设计意图，而是语言特性的副作用。
为什么这是反模式？
接口的核心职责是定义“能做什么”（行为契约），而非“配置成什么样”（数据状态）。混用会导致：
-
语义污染：接口名如
UserService突然包含DEFAULT_PAGE_SIZE，违背单一职责 -
意外继承：实现类被迫继承无关常量，可能与自身字段名冲突（如子类也定义
TIMEOUT_MS） - 无法控制访问范围：所有常量强制 public，无法设为 package-private 或 protected
- 难以测试和替换：硬编码值无法被 Mock 或运行时动态覆盖（比如不同环境需要不同 URL）
- 版本升级风险：修改接口常量值，所有实现类二进制兼容性可能被破坏
正确替代方案
根据使用场景选择更清晰、可控的方式：
-
配置类（推荐用于全局常量）：
创建public final class Constants，所有字段用private static final声明，提供静态 getter（可选）或直接 public static final（若确定永不变更） -
枚举（推荐用于有限集合的命名常量）：
如状态码、协议类型、业务类型等，用enum Status { SUCCESS, FAILED, PENDING }，自带类型安全和文档能力 -
配置属性文件 + 类型安全封装：
使用@ConfigurationProperties（Spring）或自定义加载器，把常量从代码移至application.yml，再注入到服务类中 -
接口配套的常量接口（仅限极小范围、强耦合场景）：
若某组常量**严格绑定**于某个接口的行为逻辑（如 HTTP 方法名对应 REST 接口），可新建HttpMethodConstants类，而非塞进接口本身
历史遗留代码怎么处理？
遇到老项目里满屏的接口常量，别急着全删。优先做三件事：
- 定位哪些常量实际被多个模块共用；未被引用的直接删除
- 将高频使用的常量统一迁移到新
Constants类，并用 IDE 全局重命名确保调用处更新 - 对仍需“接口级可见”的场景（如 SPI 扩展点约定），改用注解标记或独立契约接口，而非靠字段继承
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
