接口中的 static 方法不能被实现类重写，因其属于接口自身的静态工具函数，编译期绑定调用目标，不参与多态与继承体系，仅能通过接口名调用，设计上用于统一辅助逻辑而非可变行为。
接口中的 static 方法不能被实现类重写，根本原因在于它的设计定位和运行机制——它不属于实例行为，不参与多态，也不进入继承体系的调用链。
static 方法是接口自身的工具方法，不是“可继承的行为”
Java 接口从 8 版本起允许定义 static 方法，但这类方法本质上是属于接口本身的静态工具函数，就像 Math.max() 属于 Math 类一样。它不依赖任何实现类的实例状态，也不需要通过对象去调用。
- 只能通过接口名直接调用，例如
MyInterface.doWork() - 实现类不会自动获得这个方法，也不能在类中声明同签名的
static方法来“覆盖”它（那只是另一个独立的静态方法） - 编译器不允许在实现类中对接口 static 方法加
@Override注解——加了会直接报错
没有运行时分派，就没有重写的前提
重写（override）的前提是动态绑定：JVM 在运行时根据实际对象类型查找并执行对应方法。而 static 方法使用的是 invokestatic 指令，在编译期就锁定了调用目标——只看方法所属的类或接口，不看引用指向谁。
- 接口 static 方法的调用目标在编译时就确定为该接口，与实现类无关
- 即使你写
new MyImpl().xxx()，只要xxx是接口的 static 方法，语法上就不合法；必须写成MyInterface.xxx() - 这和父类 static 方法被子类“隐藏”是同一原理：不是重写，而是编译期静态解析
设计意图明确：避免混淆工具逻辑与对象行为
Java 把接口 static 方法定位为语义相关的辅助功能，比如工厂构建、参数校验、常量计算等。如果允许实现类重写，就会破坏这种清晰边界：
- 一个
PaymentService.createRefund()应该是统一的创建逻辑，不该因实现类不同而改变含义 - 若需差异化行为，正确做法是定义
default方法（可被实现类重写），或把逻辑下沉到实例方法中 - 强行让 static 方法支持重写，反而会让调用者无法预测行为，也违背“类级别工具”的初衷
替代方案更合理：用 default 或实例方法承载可变逻辑
如果你发现“想让每个实现类提供自己的 static 版本”，说明这个逻辑其实依赖具体实现，不适合放在 static 方法里：
- 改用
default方法：所有实现类自动继承，也可选择重写 - 提取为实例方法：由实现类各自实现，天然支持多态
- 配合工厂方法：接口定义
static工厂方法（如from(String type)），内部根据参数返回不同实例，再委托给实例方法处理
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
