Java泛型采用类型擦除是为了向后兼容旧JVM和遗留代码，使List<String>编译后变为原始List，保持二进制兼容；JVM字节码不支持泛型语义，擦除避免了指令集与类加载器改造；编译器承担类型检查与自动强转，确保类型安全。
因为Java泛型的设计目标是向后兼容，而不是运行时类型丰富性。它选择在编译期承担全部类型检查责任，换来了与Java 1.4及更早版本代码、JVM的无缝共存。
核心动因：兼容旧JVM和海量遗留代码
Java 5引入泛型时，已有数百万行不带泛型的代码（如List、Map）在生产环境稳定运行。若泛型信息保留在字节码中：
- 旧版JVM无法识别含泛型的类文件，直接拒绝加载；
- 已部署的框架、库、应用将大面积崩溃；
- 整个Java生态会面临不可承受的升级断层。
类型擦除让List<String>编译后变成原始类型List，与Java 1.4的List完全二进制等价——这是最务实的取舍。
JVM字节码本身不支持泛型语义
JVM指令集（如invokevirtual、getfield）只认原始类型（Object、int等），没有“泛型类型”这一概念：
立即学习“Java免费学习笔记（深入）”；
- 若保留泛型，需扩展class文件格式、新增JVM指令、重写类加载器逻辑；
- 每个List<String>、List<Integer>都得视为不同类，方法区可能爆炸式膨胀；
- JIT编译器难以对泛型做统一优化，反而拖累性能。
编译器接管全部类型安全职责
擦除不是放弃安全，而是把校验前移、把转换自动注入：
- 写list.add(42)到List<String>，编译器立刻报错；
- 调用list.get(0)，编译器自动补上(String)强转；
- 遇到<T extends Number>，擦除为Number而非Object，保留最小必要约束。
对比其他语言：历史路径决定技术方案
C#的泛型能运行时保留类型，是因为CLR从诞生起就内置支持；C++模板靠编译期实例化，但带来代码膨胀。Java没有这样的起点，只能用擦除换兼容——这不是缺陷，而是权衡后的工程共识。
