多重上界泛型（如<T extends Comparable<T> & Serializable>）类型擦除后仅保留第一个上界（按源码从左到右顺序），其余边界仅用于编译期校验，运行时不可见；Java语法强制类上界必须排首位，JVM不支持交集类型，故需明确可实例化的运行时类型。
多重上界泛型（如 <T extends Comparable<T> & Serializable>）在类型擦除后，只保留第一个上界作为擦除目标类型，其余边界仅用于编译期校验，运行时不可见。
第一边界由声明顺序决定
Java 规定：当泛型参数有多个上界（用 & 连接）时，擦除结果取 extends 后出现的第一个类型——无论它是类还是接口。这个“第一个”是源码中从左到右书写的顺序，不是按继承关系或语义优先级判断的。
-
<T extends Number & Comparable<T>>→ 擦除为Number -
<T extends Runnable & Cloneable & AutoCloseable>→ 擦除为Runnable -
<T extends Object & Serializable>→ 擦除为Object（Object是隐式上界，但显式写出时仍算第一个）
类必须排在第一位
Java 语法强制要求：如果多个上界中包含一个**类**，它必须放在最前面。否则编译不通过。因此实际能生效的第一边界，总是那个唯一的、位于首位的类；若全是接口，则取最左边的接口。
- ✅ 合法：
<T extends ArrayList & List>→ 擦除为ArrayList - ❌ 非法：
<T extends List & ArrayList>（编译报错：类不能出现在接口之后）
擦除后其他边界不参与类型替换
第二及后续上界（如 Serializable、Cloneable）不会影响擦除后的字段类型、方法签名或字节码结构。它们只在编译阶段用于约束实参类型、检查方法调用合法性，例如确保你能在泛型变量上调用 writeObject() 或 clone() —— 但这些检查在运行时已不存在。
立即学习“Java免费学习笔记（深入）”；
- 擦除后字段仍是
Comparable data，不是Comparable & Serializable - 无法在运行时通过
instanceof判断是否实现了第二个接口 - 反射获取泛型信息时，原始类型仍是第一个上界，其余边界需通过
getTypeParameters()单独提取
为什么这样设计
JVM 类型系统不支持“交集类型”（intersection type），而 Java 泛型必须映射到 JVM 原生类型。选择第一个上界，是为了保证擦除后有一个明确、可实例化的运行时类型（比如 Number 可以 new，Comparable & Serializable 不可 new）。这也与 Java 的单继承模型一致——子类只能有一个直接父类，擦除逻辑延续了这一语义约束。
