Java泛型在运行时仅保留原始类型，类型擦除是为兼容旧JVM的设计选择；隐式强制转换由编译器插入，若运行时对象类型不匹配则抛ClassCastException，需通过禁用原始类型、使用上界通配符、运行时校验及TypeToken等机制主动防御。

Java泛型在运行时没有“类型”，只有“原始类型”。类型擦除不是缺陷，而是设计选择——它让泛型代码能跑在老JVM上，代价是编译期的类型安全无法延续到运行时。真正要规避ClassCastException，关键不是绕开擦除，而是认清擦除后的真实状态，并在关键节点主动补位。

泛型擦除后，运行时只剩“原始类型+强制转换”

所有泛型集合（如List<string></string>、List<integer></integer>）在运行时都退化为List；所有泛型字段或返回值（如T getValue()）都变成Object。编译器悄悄在调用处插入强制转换，比如：

• String s = list.get(0); → 实际执行的是 String s = (String) list.get(0);
• 这个(String)不是你写的，是编译器加的，且只在编译期检查——运行时只要get(0)返回的不是String，就立刻抛ClassCastException
• 而这种不匹配，常源于原始类型（raw type）混入、反射操作、或跨模块未校验的数据传递

三类高危场景必须手动防御

擦除本身不报错，但以下场景会让隐式强转在运行时突然失败：

• 原始类型赋值污染：把List（无泛型）赋给List<string></string>变量，再往里加File对象，取出来转String必崩
• 通配符使用不当：用List>接收数据后，直接(String) list.get(0)，跳过编译检查，风险完全暴露在运行时
• 反射获取集合元素：通过Field.get(obj)拿到一个List，即使源码声明为List<date></date>，反射返回的仍是Object，强转前无任何保障

实战中可落地的规避策略

不依赖“别出错”，而靠机制兜底：

• 禁用原始类型：在IDE中启用“Raw type usage”警告，所有集合声明必须带泛型，避免List list这类写法
• 用上界通配符替代裸通配符：把List>换成List extends CharSequence>，读取时自动获得CharSequence安全视图，无需强转
• 对关键集合做运行时类型校验：自定义包装类（如CheckedList<t></t>），构造时传入Class<t></t>，add()前用clazz.isInstance(item)拦截非法元素
• 反射场景统一用TypeToken或ParameterizedType提取泛型签名：例如((ParameterizedType) field.getGenericType()).getActualTypeArguments()[0]，虽不能100%恢复（受编译选项影响），但比盲目强转可靠得多

记住一个核心判断原则

只要某处代码出现显式或隐式的(TargetType)，就要问：这个TargetType是否由编译器在编译期完全确定？如果不是（比如来自配置、反射、用户输入、跨层传递），就必须在强转前做instanceof或Class.isInstance()校验——擦除机制决定了，JVM不会替你多看一眼。