不该在接口里塞 static 工具方法，因其本质是类级别绑定的非多态函数，强耦合业务逻辑会破坏接口作为抽象契约的职责；仅纯计算、无状态、完全解耦的函数（如枚举转换、固定精度舍入）才可安全使用。
为什么不该在接口里塞 static 工具方法
Java 接口的 static 方法本质是类级别绑定的工具函数，和实现类无关——它不参与多态，也不随实现变化而变化。一旦你把业务逻辑强耦合进接口的 static 方法（比如 PaymentUtils.calculateFee()），就等于把领域规则“钉死”在契约层。后续费率策略变、币种扩展、风控校验加逻辑，都得改接口——这违反了接口作为抽象契约的设计本意。
哪些场景下用 interface static 是合理且安全的
只有当函数满足「纯计算」「无状态」「与实现完全解耦」时，才适合放在接口里。典型例子：通用格式转换、基础校验、常量组合封装。
-
OrderStatus.fromCode(int code)：仅靠输入码查枚举，不依赖任何 DAO 或配置 -
Money.roundToCent(BigDecimal amount)：固定四舍五入到分，不读取汇率或精度配置 -
IdGenerator.nextOrderId(String prefix)：纯字符串拼接 + 时间戳，不调用分布式 ID 服务
关键判断标准：该方法能否脱离 Spring Context、数据库、外部 API 独立单元测试？ 如果不能，就别放接口里。
替代方案：比 interface static 更清晰的组织方式
业务工具函数真正的归属地是「领域服务类」或「专用工具类」，而不是接口。它们能自然承载依赖、支持 mock、便于版本演进。
- 用
@Service类封装带依赖的逻辑：比如PaymentCalculationService注入RateConfigRepository - 用
final class+ 私有构造器定义无状态工具：如OrderValidationUtils，所有方法static但独立于任何接口 - 若需统一入口，用静态导入代替继承：在调用处
import static com.example.order.OrderValidationUtils.*;，而非让业务类去实现某个带工具方法的接口
注意：interface 中的 static 方法无法被子接口 default 方法覆盖，也无法被 private static 封装——这意味着一旦发布，修改成本远高于普通工具类。
如果硬要用 interface static，必须避开的坑
真要放，务必守住三条线：
- 绝不调用
Spring Bean（ApplicationContext.getBean()是反模式） - 参数和返回值类型必须是 JDK 原生或不可变对象（禁止传
EntityManager或HttpServletRequest） - 方法体里不能出现
try-catch捕获受检异常（否则所有调用方被迫处理），要么抛RuntimeException，要么转成 Optional 返回
最隐蔽的问题是：IDE 会把接口的 static 方法提示为“可从任意实现类上调用”，造成一种“属于该领域”的错觉——其实它跟那个实现类一毛钱关系都没有。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
