Java泛型采用类型擦除是为了兼容旧JVM和代码，编译时将泛型参数替换为Object或上界类型，运行时无法获取具体类型参数，但编译器通过类型检查和自动转型保障类型安全。
Java泛型之所以做类型擦除，根本原因不是技术做不到，而是为了不改JVM、不破兼容、不增负担——它是一次务实的设计妥协。
擦除是怎么发生的
编译器在把.java变成.class时，会系统性地抹掉所有泛型参数，只保留“原始类型”：
-
无边界泛型（如
）→ 擦成 Object ：Box和 Box 都变成 Box，内部字段和方法参数全转为 Object -
有上界泛型（如
）→ 擦成上界类型 ：T 被替换成 Number，方法返回值、参数类型都按 Number 处理 -
多上界（如
）→ 擦成第一个上界 A ：B 的约束仅在编译期生效，运行时不可见
为什么非擦不可
Java 5 引入泛型时，JVM 字节码规范早已固定。如果强行让 JVM 认识泛型，就得：
- 重写整个类加载机制和字节码验证逻辑
- 为每个泛型组合（List
、List 、List …）生成独立 class 文件 → 类爆炸 - 旧代码（比如只用 List 而不用 List
的库）完全无法调用新泛型类
擦除让 ArrayList
立即学习“Java免费学习笔记（深入）”；
擦除带来的典型影响
这些不是 bug，而是擦除机制的自然结果：
-
运行时无法区分泛型类型：list1.getClass() == list2.getClass() 返回 true，哪怕一个是 List
，一个是 List -
不能直接创建泛型数组：new ArrayList
[10] 编译失败，因为运行时不知道 String 是什么 -
反射可绕过类型检查：用 list.getClass().getMethod("add", Object.class).invoke(list, "hello") 能往 List
里塞字符串，后续 get() 强转就抛 ClassCastException -
无法在运行时获取泛型实参：new ArrayList
() 之后，this.getClass().getTypeParameters() 拿不到 String，只能靠 ParameterizedType + 上下文推断（如父类声明）
擦除不等于没用，安全靠编译器兜底
虽然运行时没泛型，但编译器全程盯紧：
- 你写 list.add(123) 到 List
，编译直接报错 - 你写 String s = list.get(0)，编译器自动补上 (String) 强转 —— 这个转型动作是它悄悄加的
- 当泛型类继承非泛型父类或实现原始接口时，编译器还会生成桥接方法（bridge method），保证多态调用不崩
本质上，泛型的安全性全押在编译期；运行时信任你没用反射“开后门”。
基本上就这些。擦除不是缺陷，是 Java 在工程现实和语言理想之间划出的一条清晰分界线。
