空接口是jvm硬编码识别的标记接口，如serializable，用于触发运行时行为；自定义空接口缺乏jvm支持、工具链识别弱、扩展性差，新项目应优先使用注解。
空接口在 Java 里不是语法糖，也不是“没用的摆设”，而是 JVM 和编译器协同识别的一类特殊类型——它不提供任何方法，但能触发运行时行为或编译期检查。
什么是标记接口（Marker Interface）
标记接口是只声明、不定义任何方法的 interface，比如 Serializable、Cloneable、Remote。JVM 在运行时通过 instanceof 或反射检查类型是否实现该接口，从而决定是否允许序列化、克隆或远程调用。
- 它不靠方法签名起作用，靠的是“类型存在性”本身
- 不能靠继承或默认方法模拟——JVM 层面硬编码识别这些接口名
- Java 5 引入注解后，多数新设计改用
@interface，但老接口仍保留，因为兼容性要求强
为什么不能用普通接口或抽象类替代
你写一个空的 interface MyMarker，自己用 if (obj instanceof MyMarker) 判断，看起来一样，但和标准标记接口有本质区别：
-
Serializable被ObjectOutputStream的 writeObject() 方法强制检查；没实现就抛NotSerializableException -
Cloneable不是给clone()方法提供重载依据，而是告诉 JVM “允许调用父类 protected clone()”，否则抛CloneNotSupportedException - 抽象类无法多继承，而标记行为常需叠加（比如一个类既要可序列化又要可克隆）
自定义标记接口的实际风险
现在写个空 interface Loggable 然后到处 if (x instanceof Loggable)，看似灵活，实则埋坑：
立即学习“Java免费学习笔记（深入）”；
- 没有 JVM 支持，纯靠人工判断，容易漏检或误判
- IDE 和静态分析工具无法推导语义，
@NonNull这类注解都比它更易被工具链识别 - 如果未来想加方法（比如
logLevel()），就破坏了“标记”语义，所有实现类必须改，违背初衷 - 相比
@Loggable注解，它无法携带参数、不能设置保留策略（RetentionPolicy.RUNTIME）、也不能用于方法/字段粒度
什么时候真该用空接口
除非你在开发框架底层、需要与 JVM 原生机制联动，或者维护遗留系统中已广泛使用的标记逻辑，否则别碰。
- 新项目统一用注解：比如 Spring 的
@Service、JUnit 的@Test，它们语义清晰、可配置、可组合 - 若必须做运行时类型分发，优先考虑
Class.isAssignableFrom()+ 显式注册，而不是依赖接口实现关系 - 注意
Serializable的陷阱：子类不显式声明，会继承父类的序列化能力——但父类没实现时，子类即使空实现也会被当成可序列化，可能引发意外反序列化漏洞
真正难的不是写个空 interface，而是判断它是否值得存在；一旦选错载体，后续所有扩展都会绕着这个设计打转。
