多重边界要求父类必须放在最前且唯一，接口可多个；因类型擦除需以父类为原始类型，故T extends Number & Comparable合法，而T extends Comparable & Number非法。
要让泛型参数既继承某个具体父类，又实现多个接口，就得用多重边界（Multiple Bounds）——语法是 T extends 父类 & 接口1 & 接口2。关键点只有一个：父类必须放在最前面，且只能有一个；后面全得是接口，数量不限。
为什么必须把父类放最前？
这是 Java 类型擦除机制决定的。编译后，泛型会被替换成第一个上界类型（即父类），后续接口信息只用于编译期校验。如果写成 T extends Comparable & Number，编译直接报错——因为 Comparable 是接口，不能当擦除后的原始类型。
- 合法：
& Serializable> - 非法：
& Number> - 非法：
实战场景：带校验、可序列化、支持比较的配置实体
假设你有一个基类 ConfigBase，所有配置都继承它；同时要求该配置能被校验（Validatable）、能持久化（Serializable）、还能参与排序（Comparable）：
public interface Validatable {
boolean isValid();
}
public class ConfigBase {
protected String id;
public ConfigBase(String id) { this.id = id; }
}
public class SafeConfigProcessor<t extends configbase validatable serializable comparable>> {
public void saveAndSort(List<t> configs) {
configs.forEach(c -> {
if (!c.isValid()) throw new IllegalArgumentException("Invalid config: " + c.id);
});
Collections.sort(configs); // 可安全调用 compareTo
// 后续可直接 writeObject，因实现了 Serializable
}
}</t></t>
此时传入的类型必须三者兼备，比如：
- ✅
class DbConfig extends ConfigBase implements Validatable, Serializable, Comparable - ❌
class ApiConfig extends ConfigBase implements Validatable（缺 Serializable 和 Comparable）
常见错误与避坑提醒
多重边界看着简单，实际容易踩三个坑：
- 接口重复声明无效：写成
T extends A & B & B不报错但无意义，B 只校验一次 - 泛型接口需带类型实参：
Comparable不能写成Comparable，否则类型不匹配 - 继承链中边界会叠加：若父类已声明
，子类再写T extends Number & Serializable
替代方案对比：什么时候不该用多重边界？
如果只是临时需要组合能力，而不想暴露复杂泛型，可考虑更轻量的方式：
- 用组合代替泛型约束：把
Validatable和Serializable的逻辑封装进工具方法，参数用ConfigBase，运行时检查接口实现（牺牲编译期安全） - 用标记接口+工厂模式：定义空接口
SafeConfig，让具体类显式实现它，泛型只需 - 避免过度约束：若
Serializable仅用于日志打印而非网络传输，其实没必要强制——留到真正序列化的环节再检查更合理
