java泛型类型擦除是编译期按规则替换为具体类型的机制：无界→object，单上界→上界类型，多上界→首个接口，并自动插入强制转换；运行时泛型信息丢失，但signature属性保留元数据供反射读取。
Java 泛型的类型擦除不是“删掉就不管了”，而是一套有明确规则的编译期转换机制。它让泛型在不改动 JVM 的前提下，既提供编译期类型安全，又保持与旧代码完全兼容。
擦除不是简单删掉，而是按规则替换成具体类型
编译器不会把所有 <t></t> 都粗暴换成 Object。它会根据泛型是否有边界，选择最合适的替代类型：
- 无界泛型（如
<t></t>、<e></e>）→ 擦除为Object - 单上界泛型（如
<t extends number></t>）→ 擦除为Number - 多上界泛型（如
<t extends runnable serializable></t>）→ 擦除为第一个接口，即Runnable
擦除后还要自动补上强制转换，保证运行时不出错
比如写 List<string> list = new ArrayList(); String s = list.get(0);</string>，编译器实际生成的字节码等效于：
List list = new ArrayList(); String s = (String) list.get(0);
这个 (String) 强制转换不是你写的，是编译器悄悄加进去的。它出现在所有需要还原类型的地方，比如方法返回值、泛型字段读取、泛型方法调用结果等。
擦除发生在字节码层面，但部分签名仍保留在 class 文件里
JVM 运行时确实看不到 List<string></string>，所有泛型集合在运行时都是原始类型 List。你可以用反射验证：
new ArrayList<string>().getClass() == new ArrayList<integer>().getClass()</integer></string> 返回 true
不过，类、方法、字段的泛型声明（比如 public <t> T getFirst(T[] arr)</t>）会被编译器以 Signature 属性形式写入 class 文件常量池。通过反射 API（如 Method.getGenericReturnType()）还能读到这些信息——但这只是“元数据”，JVM 执行时不参与类型判断。
擦除带来的典型限制，都源于运行时类型不可知
正因为泛型信息在运行时不存在，所以会出现这些常见现象：
- 不能用
instanceof判断泛型类型：if (list instanceof List<string>)</string>编译报错 - 不能直接创建泛型数组：
new T[10]不合法，因为T在运行时没类型可查 - 不能在静态上下文中引用类型参数：
static T defaultValue;编译失败 - 无法重载仅泛型不同的方法：
void handle(List<string>)</string>和void handle(List<integer>)</integer>会冲突，因为擦除后都是handle(List)
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
