Java泛型擦除是为保障向后兼容而刻意设计的选择：编译期将List等泛型擦除为原始类型List，复用旧字节码，插入强制转换，生成桥接方法，使新泛型代码能无缝运行于老JVM并兼容所有遗留库。
Java 泛型的类型擦除不是技术缺陷，而是有明确历史动因的设计选择——核心就是为了不打破已有生态。
向后兼容是泛型落地的前提
Java 5 之前，整个 JDK 集合框架（如 List、Map、Set）全是“裸类型”，所有方法参数和返回值都用 Object。如果泛型引入时采用 C# 那种“真泛型”（运行时保留类型信息），那么：
- 旧字节码无法在新 JVM 上直接运行（因为方法签名含泛型，JVM 会识别为未知结构）；
- 已有的第三方库（比如 Apache Commons、Hibernate 2.x）哪怕不改一行代码，也会因类加载失败而瘫痪；
- 开发者无法混合使用 List
和老式 List，迁移成本极高。
类型擦除让 List
擦除机制如何服务兼容性
编译器在擦除时严格遵循“语义等价”原则：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
立即学习“Java免费学习笔记（深入）”；
-
原始类型复用：所有 List
实例共享同一份 ArrayList 字节码，无需为每种 T 生成新类； -
桥接方法自动补位：当子类重写泛型父类方法（如
void add(T) → void add(String)），编译器悄悄插入桥接方法，确保多态调用不崩； -
强制转换由编译器兜底：从 List
取元素时，编译器自动加 (String)，把运行时 Object 安全转回目标类型——用户写的简洁，底层兼容不打折。
代价与权衡清晰可见
牺牲运行时泛型信息，换来的是零摩擦升级路径。这解释了为什么：
- 你不能写 new T[10]（运行时不知道 T 是什么）；
-
instanceof List
编译不过（JVM 根本没有 List 这个类型）； - 静态字段不能用 T（所有 Box
和 Box 共享同一个 static Object cache）。
这些限制不是疏忽，而是兼容性硬约束下的必然结果。Java 没有选“更强的泛型”，而是选了“所有人都能立刻用上的泛型”。
本质上，类型擦除是 Java 在创新与稳定之间划出的一条务实分界线。
