接口静态方法不能替代单例，但能替代无状态工具类的私有构造器；它天然禁止实例化、无需防御性构造器、调用方式不变，但不支持状态、继承、mock及依赖注入。
接口静态方法不能替代单例，但能替代工具类的私有构造器
Java 接口中的 static 方法无法实现单例语义——它没有实例、不维护状态、不可被继承重写，也不存在“唯一对象”的生命周期控制。但它确实能干净地替代传统工具类中「私有构造器 + 全静态方法」的惯用写法，前提是该工具类本身是无状态的。
为什么工具类常用私有构造器？问题在哪？
典型写法是：private Utils() {} 防止被实例化，只暴露 public static 方法。这种设计初衷是好的，但带来三个隐性负担：
- 每个工具类都得重复写一遍私有构造器，且容易被新人误删或漏写
- 构造器本身会占用字节码空间，哪怕从不调用
- IDE 或静态检查工具（如 ErrorProne）可能报
UtilityClassWithPublicConstructor警告，而你只能靠注释或 Suppress 抑制
接口天然禁止实例化，static 方法可直接定义，无需任何防御性构造器。
用 interface 替代 class 工具类的实操要点
把原 StringUtils 类改成 StringUtils 接口，只需注意以下几点：
- 所有方法必须声明为
public static（Java 8+ 中接口的static方法默认public，但显式写出更清晰） - 不能定义非
static字段；若需共享常量，可用public static final（接口字段隐式具备这三性） - 不能有构造器，也不允许
new StringUtils()—— 编译器直接拒绝，比私有构造器更彻底 - 调用方式完全不变：
StringUtils.isBlank(str)，和原来一样
示例：
public interface StringUtils {
public static boolean isBlank(String s) {
return s == null || s.trim().isEmpty();
}
public static String defaultString(String s) {
return s == null ? "" : s;
}
}
容易踩的坑：什么时候不该用接口替代？
一旦工具逻辑开始依赖可变状态或需要注入依赖，接口就不再适用：
- 如果你在工具类里用了
private static final Logger logger = LoggerFactory.getLogger(...)—— 这没问题，仍是无状态 - 但若出现
private static Map<string object> cache = new ConcurrentHashMap()</string>，且这个 cache 会被多线程写入并影响后续行为，那说明它已不是纯工具，而是有状态组件，应改用依赖注入或显式生命周期管理 - 若方法内部要调用
this、访问非静态字段、或需要被子类覆盖，接口静态方法完全无法支持 —— 此时应回归普通类 + 依赖注入，而不是硬套接口
最常被忽略的一点是：接口静态方法无法被 Mockito 等框架 mock，如果测试中需要替换某工具方法的行为（比如模拟网络失败），就必须保留类形式，并配合函数式参数或策略接口来解耦，而不是依赖接口静态方法本身。
