不推荐在接口中定义静态变量，因其违背接口仅定义行为契约的设计本意，混入状态导致抽象边界模糊、逻辑耦合增强、命名冲突、维护困难；应改用final类、枚举或领域专属类组织常量。
不推荐在接口中定义静态变量，根本原因在于这违背了接口的设计本意——它该描述“能做什么”，而不是“持有哪些值”。
接口的核心职责是定义契约
接口本质是一份行为协议。它告诉实现类：“你必须提供这些方法”，而不是“你得共享这些数据”。一旦在接口里放变量（哪怕声明为 static final），就悄悄把状态信息混进了契约里，模糊了抽象边界。
- 用户看到一个接口，预期是关注方法签名和语义，不是翻常量字段
- IDE 自动补全时，实现类会把接口常量也列出来，容易误用或误以为是该类自身能力的一部分
- 接口被多个无关模块实现时，强行共享同一组常量，逻辑耦合变强，而非松散协作
静态变量会引发命名与维护风险
当多个接口都定义同名常量（比如 STATUS_OK、TIMEOUT_MS），而某个类同时实现它们，编译器直接报错——你得手动加限定前缀，破坏了简洁性。
- 修改一个常量值，所有实现类自动“继承”变更，但没人显式声明依赖，容易遗漏回归测试
- 常量含义随业务演进可能分化，但接口无法分版本，只能硬着头皮共用，后期难以拆解
- 无法对常量做文档分级（比如只对内部模块可见），public static final 天然全局暴露
有更清晰、更可控的替代方案
Java 早已提供语义明确、职责单一的常量组织方式，无需借接口之名。
- 用 final 类 + 私有构造器：如
public final class ApiConstants { private ApiConstants() {} public static final int TIMEOUT = 5000; } - 用 枚举 管理有业务含义的常量集：如
public enum HttpStatus { OK(200), NOT_FOUND(404); ... } - 按领域建模，把常量放在最贴近使用场景的类里：比如数据库相关常量放进
JdbcConfig，而非泛泛的CommonConstants接口
接口加常量看似省事，实则埋下理解成本和重构阻力。真正干净的设计，是让每个构件各司其职：接口管行为，类管状态，枚举管取值域。
