Java泛型擦除类型的根本原因不是技术做不到而是为了不改变JVM、不破兼容不增加负担——这是一个务实的设计妥协。擦除是怎么发生的编译器在把.java变成.在class中所有泛型参数都会被系统地抹去只保留“原始类型”无边界泛型(如→ 擦成 ObjectBox 和 Box 都变成 Box内部字段和方法参数全转换为 Object有上界泛型(如→ 擦成上界类型T 被替换成 Number方法返回值和参数类型按照 Number 处理多上界如→ 擦成第一个上界 AB 限制只在编译期生效运行时不可见为什么一定要擦Java 5 引入泛型时JVM 字节码规范已经固定。如果强行让路。 JVM 了解泛型必须重写整个类加载机制和字节码验证逻辑对于每一个泛型组合List、List、List…)生成独立 class 文件 → 类爆炸旧代码(比如只用 List 而不用 List 库)根本无法调用新的泛型擦除让 ArrayList.class 和原始 ArrayList.class 运行时是同一类 —— 所有的老代码照片都跑不错。这些不是 bug但擦除机制的自然结果一般类型在运行时无法区分:list1.getClass() list2.getClass() 返回 true哪怕一个是 List一个是 List泛型数组不能直接创建new ArrayList[10] 编译失败因为我不知道操作 String 是什么反射可绕过类型检查使用 list.getClass().getMethod(add, Object.class).invoke(list, hello) 能往 List 里塞字符串后续 get() 强转就抛 ClassCastException运行时无法获得泛型实参new ArrayList() 之后this.getClass().getTypeParameters() 拿不到 String只能靠 ParameterizedType 上下文推断(如父亲声明)擦除并不意味着没用。安全取决于编译器的底部虽然运行时没有泛型但编译器一直盯着整个过程你写 list.add(123) 到 List编译直接报错你写 String s list.get(0)自动补充编译器 (String) 强转 —— 它悄悄地添加了这种转换动作编译器在继承非泛父类或实现原始接口时也会生成桥接方法bridge method确保多态调用不崩溃本质上泛型的安全性都在编译期内信任你在操作过程中无需反射“打开后门”。基本上就是这些。擦除不是缺陷而是 Java 在工程现实和语言理想之间划出清晰的界限。
