标记接口：Java类型系统中最被低估的设计武器

第一次接触“标记接口”这个概念，是在一次代码评审里。同事提了一个 PR，定义了一个空空如也的接口，名字叫 Retryable，里面一行方法都没有。当时第一个反应是：“这接口有啥用？”后来翻了《Effective Java》第41条，才意识到自己差点错过一个非常有用的设计武器。这一条讲的就是用标记接口定义类型，核心观点一句话就能说清楚：没有方法的接口，恰恰能提供最强的方法约束。

这篇内容既适合刚入门没多久，正在纠结“接口里没有方法是不是写错了”的人，也适合已经写了几年业务代码、天天在接口和注解之间做选择的人。我会从 JDK 自带的例子、一个实际业务改造、以及和标记注解的对比这几个角度，把这一条读透，再补一些生产环境里踩过的细节坑。

1. 一个空接口，为什么成了 API 设计里最被低估的“类型牌”

1.1 标记接口不是“空”，它是类型系统的一个正式成员

很多人第一次看到 Serializable、Cloneable 这种接口时会困惑：里面没有任何方法，实现了它和没实现它，代码不都照跑吗？这种理解没抓住重点。标记接口在 Java 类型系统里占据一个真实存在的地位，它不是一段需要你去实现的契约，而是一个可以被编译器识别的“身份标签”。

举个例子。你定义了一个接口：

java复制public interface Approved {
}

接着你写了一个方法，只允许发布“已审批”的内容：

java复制public void publish(Approved content) {
    // 发布逻辑
}

现在有两个类，一个实现了 Approved，一个没有：

java复制public class BlogPost implements Approved {
    // 业务代码
}

public class DraftPost {
    // 业务代码
}

神奇的事情发生了——publish(new BlogPost()) 能通过编译，publish(new DraftPost()) 直接编译报错。注意，这个拦截发生在编译期，甚至不需要跑单元测试，IDE 里就已经划了红线。

这就是标记接口的价值：它把“具有某种资格”这件事，变成了类型系统的一部分，让编译器替你把关。比较一下用注解实现同样效果：

java复制@ApprovedAnno
public class BlogPost {
}

然后方法签名只能写成：

java复制public void publish(Object content) {
    if (!content.getClass().isAnnotationPresent(ApprovedAnno.class)) {
        throw new IllegalArgumentException("没有审批标记");
    }
    // 发布逻辑
}

这个代码能把 DraftPost 传进去，然后运行到一半再炸。如果你忘了写这段检查，那连炸都不炸，线上才会出问题。两套方案放在一起，接口版的优势非常明显。

1.2 “类型”比“元数据”更底层，这是理解这一条的关键

我后来想明白一个道理：Java 的类型系统在编译期就是一把锁，而注解本质上只是贴在代码上的元数据，默认情况下编译器不会拿它做任何事。你可以在任何类、方法、字段上贴注解，编译器都不关心，只有你自己写的反射代码或者其他框架才会关心。

这意味着，注解描述的是“语义标签”，而标记接口描述的是“能力的类型”。你希望自己的 publish 方法只接受有审批能力的对象，这本质上是类型层面的约束，应该用接口；你只是希望给某个方法打个标记提醒 IDE 或者后续工具处理，那才是注解的活。

很多现成的框架，比如 Spring，大量使用 @Component、@Service 这种注解，是因为它要做的是组件扫描和装配，而不是让编译器来限制某个方法入参。这两种场景的目的完全不同，不能混为一谈。

2. 带着源码看 JDK 的标记接口案例：RandomAccess 如何影响二分查找

2.1 bina