java泛型擦除是为兼容旧代码的主动设计，核心是编译期检查、运行时无类型信息：字节码中泛型消失，jvm只认原始类型，编译器自动插入强制转换，导致无法创建泛型数组、instanceof判别具体泛型等限制。
掌握 Java 泛型擦除机制，关键不是死记规则，而是理解它“为什么这样设计”以及“它在哪儿真正起作用”。泛型擦除不是 bug，是 Java 为兼容旧代码做的主动妥协。只要抓住编译期检查 + 运行时无类型信息这个核心，就能理清绝大多数困惑。
看清擦除发生的阶段和位置
泛型只在源码和编译期存在，字节码里已经没有 <t></t>、<string></string> 这类标记。JVM 看到的永远是原始类型（Raw Type）：
-
List<string></string>和List<integer></integer>编译后都是List，它们的.class文件完全相同 -
Box<double></double>和Box<boolean></boolean>运行时都是Box.class，字段类型被擦除为Object或上界类型（如<t extends number></t>擦除为Number） - 编译器会在调用处自动插入
(String)、(Number)这类强制转换，你写的“安全取值”其实是编译器帮你补的
动手验证擦除的存在
光看理论容易空洞，用反射和运行时操作能直观感受“类型已消失”：
Java JDK 25
下载
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
- 写一个
List<integer></integer>，用反射调用add(Object)方法塞入字符串——能成功，说明运行时只认Object - 对
ArrayList<string>.class</string>调用getTypeParameters()，返回空数组；但对方法getGenericReturnType()可能拿到java.lang.String，因为方法签名里的泛型信息被保留在Signature属性中（仅限声明处，非运行时实例） - 尝试
new T[]或if (obj instanceof List<string>)</string>，编译直接报错——擦除后连类型字面量都不存在了
理解擦除带来的典型限制
这些不是“缺陷”，而是擦除机制的自然结果。遇到问题时，先想：“这需要运行时知道泛型类型吗？” 如果是，那大概率走不通：
- 不能创建泛型数组：
new T[10]不合法，因为T在运行时是未知的 - 无法用
instanceof判断具体泛型类型：list instanceof ArrayList<string></string>编译失败，只能写list instanceof ArrayList - 静态方法/静态字段不能引用类的类型参数：
static T value非法，因为静态内容属于类，而擦除后所有泛型实例共享同一个类 - 泛型类不能重载仅靠类型参数区分的方法：
void handle(List<string>)</string>和void handle(List<integer>)</integer>编译不通过，擦除后签名重复
把 PECS 原则和擦除联系起来
PECS（Producer Extends, Consumer Super）不是独立知识点，它是擦除机制下写出安全、灵活 API 的实践解法：
- 当你需要从集合读数据（Producer），用
? extends Number：编译器允许你接收List<integer></integer>，并保证get()返回Number（擦除后实际是Number，安全） - 当你需要往集合写数据（Consumer），用
? super Integer：编译器允许你传入List<number></number>，并接受Integer（擦除后底层是Object，Integer肯定能存） - 如果写成
List>，看似通用，但既不能安全读（返回Object），也不能安全写（只接受null），反而失去泛型价值
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
