Java中用多个接口限定泛型边界需使用<T extends A & B & C>语法，要求类型参数T同时实现所有接口，以满足复杂业务对象的多重契约能力，如Validatable、Auditable与Serializable等。
Java 中用多个接口限定泛型边界，核心是借助 多重上界（Multiple Upper Bounds） 语法：<T extends A & B & C>。它让类型参数 T 必须**同时实现所有列出的接口**，从而精准表达一个业务对象需具备的多种契约能力。
为什么多个接口限定比单个更贴合真实业务
单一接口（如 Serializable）只能保证一种行为；而复杂业务对象往往需要组合能力：
- 既要能校验自身（
Validatable），又要支持审计日志（Auditable） - 既需参与排序（
Comparable<T>），又得能序列化传输（Serializable） - 既遵循统一响应规范（
ApiResponse），又可被 JSON 库识别（JsonSerializable）
正确写法：接口必须排在类之后，且全部用 & 连接
语法有严格顺序要求：
- 最多只能有一个类作为上界，且必须放在最前面（如
BaseEntity） - 所有接口必须跟在类之后，用
&分隔，顺序不限 - 编译器擦除后以第一个类型（类）为原始类型，保障类型安全
示例：
立即学习“Java免费学习笔记（深入）”；
Java Maven Common
下载
Java Maven 项目审查工作流的通用输入处理。当 Java Maven 项目以 ZIP压缩包或 GitLab 仓库 URL 形式提供且需要...时使用。
public class BusinessProcessor<T extends BaseEntity & Validatable & Auditable & Serializable> {
private T item;
public void process(T t) {
t.validate(); // ✅ 来自 Validatable
t.setAuditTime(); // ✅ 来自 Auditable
// 可安全序列化、可作为 BaseEntity 子类使用
}
}
实际使用时的常见限制和检查点
不是所有类型都能通过编译，关键看是否真正满足全部约束：
-
BusinessProcessor<User>✅ 成立，前提是User确实继承BaseEntity并实现了三个接口 -
BusinessProcessor<Order>❌ 失败，哪怕只缺一个接口（比如没实现Auditable） -
BusinessProcessor<String>❌ 失败，String不继承BaseEntity，也不实现那些业务接口
IDE 通常会在声明处标红，并提示 “Type argument does not satisfy upper bounds”，这是最直接的反馈信号。
搭配泛型方法增强灵活性
可在类内部定义泛型方法，进一步细化能力调用逻辑：
public <R> R transform(T source, Function<T, R> mapper) {
if (source.isValid()) { // ✅ Validatable 提供
source.markProcessed(); // ✅ Auditable 提供
return mapper.apply(source);
}
throw new ValidationException();
}
这样既复用多重边界保障入参能力，又通过函数式参数解耦具体转换逻辑，适合配置化或插件化场景。
