接口静态方法不能被继承，只能通过接口名调用；默认方法可被子接口或实现类继承。
接口静态方法只能通过接口名调用，不能被实现类继承
Java 8 起接口允许定义 static 方法，但它和类中的静态方法有关键区别：它**不参与继承链**。哪怕某个类 implements MyInterface，也不能用 MyImpl.doSomething() 调用接口里的静态方法——编译直接报错。唯一合法调用方式只有 MyInterface.doSomething()。
常见错误现象包括：
- IDE 提示 “Cannot resolve symbol” 或 “non-static method cannot be referenced from a static context”（实际是误用了实现类名）
- 把接口静态方法当成默认方法写，漏掉
static关键字，导致编译失败
适合放进 interface 的静态方法必须满足“无 this、无实例状态”
接口静态方法体内不能访问 this，也不能读写非静态字段或调用非静态方法——因为它压根不绑定任何实例。所以它天然适合封装纯函数式逻辑：
- 输入参数 → 计算 → 返回结果，全程不依赖外部对象状态
- 比如
Comparator.naturalOrder()、Optional.ofNullable()这类工厂构造逻辑 - 比如校验字符串格式、解析枚举值、生成标准 ID 等与接口语义强相关的工具行为
反例：若方法需要读取 config.properties 或调用 new Date() 并存入某实例缓存，则不该放接口里，应交由专门的工具类或 Spring Bean 管理。
立即学习“Java免费学习笔记（深入）”；
避免和实现类同名静态方法冲突，但二者互不影响
如果接口定义了 static String format(String s)，而某个实现类也定义了签名完全相同的 static String format(String s)，它们是两个独立方法：
-
MyInterface.format("x")永远调用接口版本 -
MyImpl.format("x")永远调用实现类版本 - 不会覆盖，也不会隐式委托，更不会产生多态行为
这点容易被误认为“重载”或“重写”，其实只是名字巧合。命名时建议加前缀（如 ofEmail()、fromJson()）来降低歧义风险。
性能与兼容性：无运行时开销，但 Java 8+ 是硬门槛
接口静态方法在字节码层面就是普通静态方法调用（invokestatic），没有反射或动态分派成本。不过要注意：
- Java 7 及更早版本无法编译含接口静态方法的代码
- Android 开发需确认 target SDK 支持 Java 8+ 默认方法特性（通常 API 24+ 安全）
- 若项目仍需兼容旧 JDK，就别把核心工具逻辑塞进接口——宁可单独建
XXXs工具类（如Validators）
真正容易被忽略的是语义边界：不是所有“静态工具”都该进接口。只有当这个方法天然属于该接口的契约范畴（比如 Validator.ofEmail() 对应 Validator 接口），才值得这么做；否则只是把工具类强行拆进接口，反而破坏内聚。
