Java接口中的static方法在字节码层面使用invokestatic指令调用，与普通类静态方法完全一致，JVM不区分二者；其调用基于编译期确定的符号引用，属静态绑定，不可重写但可被子接口同名方法隐藏。
Java 接口中定义的 static 方法在字节码层面确实通过 invokestatic 指令调用，和普通类的静态方法完全一致——JVM 不区分“接口 static 方法”和“类 static 方法”，只要目标方法是 static、可访问、且签名匹配，就直接用 invokestatic。
接口 static 方法的字节码与普通类 static 方法无区别
从 JVM 规范角度看，invokestatic 指令只关心：方法是否为 static、是否在常量池中能解析为一个有效的 Methodref、访问修饰符是否允许（如 public 或包内可见）。接口中的 public static 方法满足全部条件，编译后生成的字节码和调用类中同签名的 static 方法完全一样。
- 编译器将接口名 + 方法名 + 描述符写入常量池，类型为
CONSTANT_Methodref_info - 调用处插入
invokestatic指令，操作数指向该常量池项 - JVM 运行时根据符号引用解析出具体方法入口，跳转执行（不涉及虚方法表或动态分派）
为什么不是 invokespecial 或 invokeinterface
invokespecial 用于私有方法、构造器、父类方法（super.xxx()），而接口 static 方法既非私有也非构造器，也不属于“父类调用”语义；invokeinterface 专用于实例方法的接口调用，要求对象引用在栈顶且运行时查表分派——static 方法无接收者，无需分派，故排除二者。
-
invokestatic是唯一支持“无接收者 + 编译期确定目标”的指令 - 即使方法定义在接口中，只要声明为
static，JVM 就按静态绑定处理 - 这和 Java 8 引入接口默认方法（
default）形成对比：后者用invokeinterface，因为需要对象接收者和运行时分派
验证方式：反编译看字节码
写一个简单例子：
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
interface Utils {static int add(int a, int b) { return a + b; }
}
class Test {
public static void main(String[] args) {
int x = Utils.add(1, 2); // ← 这里触发 invokestatic
}
}
用 javap -v Test 查看 main 方法字节码，会看到类似：
iconst_2
invokestatic #3 // Method Utils.add:(II)I
其中 #3 指向常量池里 Utils.add 的 Methodref，指令明确为 invokestatic。
注意：接口 static 方法不能被重写，但可被隐藏
子接口可以定义同名同签名的 static 方法，此时编译器根据调用处的**接口类型**决定调用哪个版本——字节码中 invokestatic 的符号引用由编译时类型确定，不是运行时动态选择。这进一步印证了其静态绑定本质。
- 调用
Utils.add()→ 解析到Utils接口的实现 - 若另有
AdvancedUtils extends Utils并重定义add，则AdvancedUtils.add()生成独立的invokestatic指向新方法 - 不存在“覆盖”行为，只有编译期静态绑定到声明类型的实现
