java泛型采用类型擦除机制，编译时将泛型参数替换为原始类型（如object或上界类）并插入强制转换，运行时jvm仅见擦除后的原始类型，故list与list在运行时无法区分。
因为Java泛型采用类型擦除（Type Erasure）机制，编译器在生成字节码前就把所有泛型参数替换成原始类型（如 Object 或上界类），同时插入必要的强制类型转换。运行时JVM看到的只有擦除后的原始类型，比如 List<string></string> 和 List<integer></integer> 都变成 List，自然无法区分。
类型擦除是向后兼容的硬性选择
Java 5 引入泛型时，必须让新代码能在老版本 JVM（如 Java 1.4）上运行。如果像 C# 那样在运行时保留泛型信息，旧虚拟机根本无法加载带泛型的类文件。类型擦除让泛型成为纯粹的“编译期语法糖”，字节码层面与非泛型代码完全一致，保障了整个生态平滑升级。
擦除过程的具体表现
编译器执行以下操作：
- 把无边界类型参数
<t></t>全部替换为Object - 把有边界参数
<t extends number></t>替换为Number - 在调用
get()等返回泛型值的方法处，自动插入强制类型转换，如(String) list.get(0) - 泛型类、接口、方法的类型参数全部从字节码中移除，不留下任何运行时痕迹
运行时失真的直接证据
这些现象都源于擦除后类型信息归零：
-
new ArrayList<string>().getClass() == new ArrayList<integer>().getClass()</integer></string>返回 true - 无法用
instanceof判断obj instanceof List<string></string>（编译不通过） - 不能声明
List<string>[] arr = new ArrayList<string>[10]</string></string>（会报错） - 反射获取
list.getClass().getTypeParameters()得到空数组，而ParameterizedType需依赖子类继承等间接方式抢救
它不是缺陷，而是权衡的结果
类型擦除牺牲了运行时类型灵活性，换来的是零成本兼容、更小的字节码体积、以及无需修改JVM就能支持泛型的工程可行性。你写的 List<string></string> 在编译期被严格校验，在运行期靠擦除+强转保障安全——它没“失效”，只是换了一种更底层的方式工作。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
