Java泛型采用类型擦除机制，核心原因是保障向后兼容性，确保Java 5引入泛型后仍能与旧版JVM及Java 1.4代码二进制兼容；JVM字节码本身不支持泛型语义，需编译器在编译期承担类型检查和强转插入等全部安全责任。
因为Java泛型采用的是类型擦除（Type Erasure）机制，这是语言设计时为兼容旧版本JVM和已有代码所做出的根本性取舍。
核心原因：向后兼容性优先
Java 5 引入泛型时，已有大量不带泛型的代码（如 List、Map）在生产环境运行。若让泛型信息保留在字节码中，旧版 JVM 就无法加载新编译的类——这会直接破坏整个生态。擦除机制确保：
- 泛型类（如
List<String>）编译后变成原始类型List，与 Java 1.4 的List完全二进制兼容； - 所有泛型集合、工具类都能无缝调用旧代码，反之亦然；
- JVM 无需修改指令集或类加载逻辑，避免了底层架构震荡。
JVM 本身不支持泛型语义
JVM 字节码规范中没有“泛型类型”这一概念。它的方法调用（invokevirtual）、字段访问、数组创建等指令都只认原始类型（如 Object、Integer）。如果保留泛型信息：
- 需扩展 class 文件格式和 JVM 指令，影响跨平台稳定性；
- 类加载器要区分
List<String>和List<Integer>为不同类，导致方法区爆炸式增长； - JIT 编译器无法对泛型做统一优化，性能反而下降。
编译器承担了全部类型安全责任
擦除不是“偷懒”，而是把类型检查前移到编译期，并自动生成保障逻辑：
立即学习“Java免费学习笔记（深入）”；
- 写
list.add(123)到List<String>时，编译器立刻报错； - 从
list.get(0)取值时，编译器自动插入(String)强转，把运行时 ClassCastException 提前拦截； - 遇到有界泛型（如
<T extends Number>），擦除为Number而非Object，保留最小必要约束。
对比其他语言的设计选择
C# 在 .NET 运行时直接支持泛型，每个泛型组合（List<string>、List<int>）都是独立类型——但这是建立在 CLR 从一开始就有泛型支持的基础上。Java 没有这个历史条件，只能用擦除换兼容。
