Java泛型擦除不是bug而是设计取舍，编译器将List<String>还原为List并插入强制转换，运行时JVM只认List.class；instanceof List<?>编译失败因擦除后无独立类型信息，new T[]和static T非法因T在运行时已退化为Object或边界类型，桥接方法由编译器自动生成以解决多态签名冲突。
Java泛型擦除不是bug，是编译器在你写 List<string></string> 时，悄悄把它“还原”成 List 并补上强制转换的机制——运行时JVM根本没见过 String 这个泛型参数。
为什么 instanceof List<string></string> 编译不过？
因为擦除后压根不存在 List<string>.class</string> 这个类型：所有泛型实例（List<string></string>、List<integer></integer>）在运行时都指向同一个 List.class。
- 编译器直接拒绝
if (obj instanceof List<string>)</string>—— 不是语法限制，而是语义上不可能 -
obj.getClass() == ArrayList.class永远为true，无论你声明的是ArrayList<string></string>还是ArrayList> - 想判断实际元素类型？必须靠反射查字段/方法签名里的
ParameterizedType，且仅对静态声明有效
为什么不能写 new T[] 或 static T field？
擦除让 T 在运行时变成 Object（或边界类型），但JVM无法在类加载阶段确定该构造哪个具体子类的数组，也无法把一个实例泛型变量挂到静态上下文中。
-
new T[10]编译报错：擦除后相当于new Object[10]，但语义上你要的是String[]或Integer[] -
static T cache编译失败：静态字段属于类，而T属于实例化时的类型变量，生命周期不匹配 - 绕过方案：传入
Class<t></t>类型令牌，用Array.newInstance(typeClass, size)
桥接方法（bridge method）是怎么悄悄生成的？
当你实现泛型接口（如 Comparable<t></t>）或继承泛型类时，编译器会自动生成一个“伪装”的重载方法，用来应付多态调用中擦除导致的签名冲突。
立即学习“Java免费学习笔记（深入）”；
- 例如实现
compareTo(Integer)，编译器额外生成一个compareTo(Object)桥接方法 - 这个方法你看不见，但用
getDeclaredMethods()能查到，它内部只是转型后调用你的原方法 - 它解决了“子类方法签名与父类擦除后签名不一致”的问题，但也让反射遍历时多一层干扰
最常被忽略的一点：泛型擦除不是妥协，是设计取舍——它用编译期的严格检查，换来了百万行 JDK 集合代码零修改就能跑新泛型程序。所以别试图“绕过擦除”，而是学会在擦除的前提下，用 Class<t></t>、ParameterizedType 和通配符去表达意图。
