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