泛型擦除本身不报错，但运行时因编译器隐式插入的强转（如strlist.get(0)处插了(string)）与实际类型不符而抛classcastexception；需据异常信息定位肇事调用点，检查原始类型、方法引用推断、反射及json反序列化等场景的类型匹配。
泛型擦除本身不会直接报错，但会在运行时暴露隐式强转失败——关键不是“怎么擦除”，而是“哪里悄悄加了 cast 却没对上”。排查重点是定位那个看似干净、实则藏着编译器插入转换的调用点。
看异常堆栈里真正的“肇事行”
ClassCastException 的堆栈顶通常显示类似 strList.get(0).length() 或 item.toString() 这样的代码。这不是问题源头，而是隐式转换执行后第一次使用结果的地方。真正出问题的是 strList.get(0) 这一步：编译器在这里插了 (String)，但实际返回的是 Integer 或其他类型。
- 记下异常消息中的两个类名，比如
Integer cannot be cast to String，说明某处把 Integer 当 String 强转了 - 顺着堆栈往上找，找到最近一次泛型集合取值、方法引用返回、或 Supplier.get() 调用的位置
- 检查该变量声明类型（如
List<string></string>）和它实际被赋值/构造的来源（是否来自原始 List？是否用了ArrayList::new却没绑定泛型？）
查构造方法引用和函数式接口的类型推断链
像 String::new、ArrayList::new 这类引用，本身不报错，但一旦放进泛型上下文（如 Function<integer string></integer> 或 Supplier<list>></list>），编译器会根据目标接口反推返回类型。推错就埋雷。
- 确认接收方接口是否明确带泛型，避免写成
Supplier listSupplier = ArrayList::new（原始类型接收） - 若用
cls::newInstance，注意cls是Class<t></t>，但newInstance()返回 Object，下游强转靠擦除后类型保障，极易崩 - 泛型类的构造引用（如
Pair<k>::new</k>）必须在所有使用点显式绑定 K/V，不能依赖new Pair()这种原始写法
盯住原始类型和混用场景
原始类型（raw type）是擦除失配的高发区。它允许编译通过，却把类型安全完全交给运行时，而运行时又没有泛型信息。
- 搜索代码中
List raw = new ArrayList()、Map map = new HashMap()这类声明，尤其关注后续是否被转成参数化类型（如List<string> safe = raw</string>） - 检查反射调用（
Method.invoke()、Constructor.newInstance()）返回的对象，是否未经校验就直接强转为泛型目标类型 - JSON 反序列化时，确认 Jackson/Gson 是否传了
TypeReference或ParameterizedType，否则默认反成LinkedHashMap，取元素时必崩
调试时多看运行时真实类型
别只信声明类型。在 IDE 调试器里停在异常行前，展开变量，看它的 getClass() 和实际内容；或者加一行日志：System.out.println(obj.getClass() + ", value=" + obj)。
- 对集合类，打印
list.getClass()和list.get(0).getClass()，对比声明类型与实际元素类型 - 对方法引用返回的对象，不要只看接口定义，要验证它的真实 class
- 用
instanceof做防御性判断，尤其在从泛型容器取值后、调用方法前
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
