接口中定义常量仅当其直接支撑接口方法行为时才合理，如回调标识或协议字段；否则应移至枚举或final类，避免“常量接口”模式，且方法无需显式声明public abstract。
接口中定义常量不是不可以，但必须服务于接口的核心职责——描述行为契约。如果常量和接口方法无关，或者接口只含常量，那就违背了接口的设计本意，容易引发维护隐患。
常量该不该放接口里？看它是否支撑接口行为
只有当常量是接口方法的直接参与者时，才适合放在接口中。比如：
- 回调类型标识：接口 OnLoadListener 中定义 RESULT_SUCCESS = 0 和 RESULT_ERROR = 1，供 onLoad(int result) 方法使用
- 协议字段：接口 HttpProtocol 中定义 HEADER_AUTH = "Authorization"，被其方法 addHeader(String key, String value) 引用
- 状态码枚举替代方案（极少数遗留场景）：若暂不能用枚举，且该状态仅用于此接口的返回逻辑，可保留在接口内
一旦常量泛化、通用、或与任何方法无调用/语义关联（如 UserConstant.ROLE_ADMIN），就该移出接口。
方法定义要干净，不加冗余修饰符
接口方法默认就是 public abstract，显式写出反而降低可读性：
- ✅ 正确写法：void save(User user);
- ❌ 避免写法：public abstract void save(User user);
JDK 8+ 支持 default 和 static 方法，它们应提供真正通用、对所有实现类都有价值的默认逻辑，而不是补全业务细节或替代具体类的职责。
比接口更优的常量组织方式
多数情况下，常量不应依赖接口承载：
- 优先用枚举（enum）：适用于有固定取值集合、需类型安全和语义明确的场景（如 WeekDay.MONDAY、Status.ACTIVE）
- 次选用 final 类：定义纯静态常量，配私有构造函数防止实例化，例如 ApiEndpoints.HOME_URL
- 避免“常量接口”模式：即让业务类 implements Constants 来导入常量——这会污染命名空间、引发冲突、削弱封装性
命名与可见性要克制
接口中若保留必要常量，需注意：
- 名称全部大写，单词间用下划线分隔（如 DEFAULT_TIMEOUT_MS）
- 不声明 public static final —— 接口自动赋予，显式写出是冗余
- 不试图控制访问级别：接口常量天然是 public，无法设为 package-private 或 protected，如有权限需求，说明它本就不该在接口里
