Type Erasure：泛型信息为什么运行时消失了？
TL;DR
Java 的类型擦除让泛型主要承担编译期检查，生成字节码时把参数化类型替换为上界，并插入必要的转换。本文解释它带来的兼容性优势、反射限制，以及它和 Rust 单态化路线的区别。
Java 的类型擦除让泛型主要承担编译期检查，生成字节码时把参数化类型替换为上界，并插入必要的转换。本文解释它带来的兼容性优势、反射限制，以及它和 Rust 单态化路线的区别。
你在 Java 里写了 List<String>，运行时却常常只能看到一个普通的 List。这不是编译器忘记了类型，而是 Java 采用了 Type Erasure，也就是类型擦除：泛型主要用于编译期检查，生成字节码时，很多参数化类型信息会被移除或替换成它的上界。
编译器具体做了什么
对于无界类型参数，编译器通常用 Object 替换；如果类型参数有上界，就用上界替换。需要取出具体类型时，编译器会插入必要的类型转换。某些继承场景还会生成 bridge method，以维持多态调用的表现。
结果是，List<String> 和 List<Integer> 不会在运行时变成两套全新的类。它们共享泛型声明对应的字节码，这降低了运行时开销，也让泛型代码能和早期没有泛型的 Java 代码保持兼容。
代价是什么
类型擦除让运行时无法直接知道某些参数化类型。例如，你不能简单地判断一个对象是否是 List<String>，因为 String 这一层信息已经不在普通运行时类型里。反射、序列化和泛型数组因此需要额外技巧，例如显式传入 Class<T>，或保存一个类型令牌。
擦除还解释了为什么某些错误直到取值时才出现：如果代码通过原始类型绕过了编译器检查，编译器可能在读取位置插入转换，真正不匹配时才抛出异常。
和 Rust 的路线有什么不同
Java 更重视兼容既有 JVM 和旧代码，于是采用共享字节码与类型擦除；Rust 默认倾向于对每个具体泛型实例做单态化，换来更直接的机器代码和静态分发。两种方案都合理，只是把成本放在不同地方：一个牺牲部分运行时类型信息，一个可能增加编译时间和二进制体积。
读者应该记住
Type Erasure 的关键词是“编译期知道，运行时不一定保留”。它解释了 Java 泛型的兼容性优势，也解释了反射、序列化和泛型数组中的许多限制。
