接口不应定义常量，因其违背行为契约本质，导致耦合加深、灵活性丧失、封装破坏及修改成本高；应改用枚举、配置类或依赖注入等方式分离配置与契约。
接口里定义常量（比如 public static final int MAX_RETRY = 3;）看似方便，实则违背面向对象设计的初衷：接口应描述“能做什么”，而不是“配置成什么样”。它把本该属于具体实现或配置层的细节，硬塞进了契约层，导致调用方被迫依赖这些常量，耦合加深，后续修改成本高——改一个值，可能要重编译所有实现类，甚至影响下游模块。
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
为什么接口常量是坏味道
– 接口本质是行为契约，不是配置中心。把 TIMEOUT_MS、DEFAULT_PAGE_SIZE 放进接口，等于让所有实现者“统一服从一个硬编码的默认值”，丧失灵活性；
– 常量被 public static final 强制公开，任何类都能直接引用，破坏了封装边界；
– 多个实现类若需不同取值（如微信支付超时 5 秒，余额支付超时 10 秒），就只能绕开接口常量另写逻辑，反而让代码更混乱；
– 一旦常量名或值变更，所有引用它的类都要重新编译，违背“稳定抽象原则”。
替换成配置类或枚举
把常量从接口中剥离，移到专用的、有明确语义的类型中：
– 简单通用常量（如状态码、错误码）→ 定义为 public enum，例如 PaymentStatus、ErrorCode；
– 业务级配置项（如重试次数、超时阈值）→ 提取为独立配置类，如 RetryConfig 或 PayOptions，支持构造传参或 Builder 构建；
– 若需全局共享且不可变，可用 final class + 私有构造 + 静态常量字段，但不暴露给接口，仅供内部使用。
通过参数或依赖注入传递可变值
不要让接口方法隐式依赖某个常量，而是显式接收：
– 把原本写死在接口里的 MAX_RETRY，改为方法参数：boolean executeWithRetry(int maxRetries)；
– 或将整套配置作为对象注入，例如在实现类构造时传入 PayStrategy，其内部持有 timeoutMs 和 maxRetries；
– Spring 项目中，优先用 @ConfigurationProperties 绑定 yml 配置，再通过构造器注入到服务类，完全脱离接口。
保留接口只声明行为契约
重构后，接口应干净、专注、可扩展：
– 只含抽象方法（Java 8+ 可酌情加 default 或 private 方法做共通逻辑）；
– 不出现任何 public static final 字段；
– 方法签名体现意图而非假设，例如用 process(ProcessingContext context) 替代 process()，把上下文和策略封装进去；
– 若真有“必须统一”的标识（如协议版本号），应由具体实现类自己决定如何实现，接口不参与定义。
