泛型擦除本身不直接导致反射调用出错，但使反射失去类型约束，强制转换时暴露ClassCastException；根本原因是反射绕过编译期泛型检查，将类型错误延迟至运行时爆发。
泛型擦除本身不直接导致反射调用出错，但会让反射失去类型约束能力，从而在后续强制转换时暴露 ClassCastException。关键不在“反射做了什么”，而在于“反射绕过了编译器的泛型检查，把本该被拦在编译期的类型错误，拖到了运行时才爆发”。
为什么反射调用容易触发擦除引发的 ClassCastException
Java 反射（如 Method.invoke()、Constructor.newInstance()、Field.get()）返回的都是 Object 类型。即使方法声明返回 List
真正出错的环节，往往发生在你拿到反射结果后，再做显式或隐式转换时：
- 显式强转：比如 (List<String>) method.invoke(obj) —— 编译通过，但若实际返回的是 ArrayList<Integer>，运行时就崩；
- 隐式强转：比如把反射结果赋给 List<String> list = ...，然后调用 list.get(0).length() —— 编译器悄悄插了 (String) list.get(0)，Integer 转 String 就抛异常；
- 反序列化+反射混合场景：Jackson/Gson 用反射创建对象，但未传入 TypeReference，结果把 JSON 数组反成 List<LinkedHashMap>，你却当成 List<User> 用。
三步定位反射相关 ClassCastException
不要只盯着异常堆栈里那行“xxx cannot be cast to yyy”，要逆向查清“谁给了你这个错类型对象”：
- 看异常消息中的具体类型对：例如 java.util.LinkedHashMap cannot be cast to com.example.User，说明某处把 Map 当成了 User；立刻搜索代码中所有对 User 类型的强转，尤其是反射调用后的赋值或取值；
- 查反射调用的目标方法/字段签名：确认它声明的返回类型（如 public List<User> getUsers()），再检查它的实际实现——是否内部用了原始集合、手动 new ArrayList()、或从 JSON/DB 直接塞了非泛型数据？
- 验证反射调用前后的类型流：在 invoke 前打日志，打印返回值的 getClass().getName() 和 toString()；如果返回的是 ArrayList，再遍历前几个元素，打印 e.getClass().getName()，确认是不是 LinkedHashMap 或 Integer 等“意外类型”。
安全使用反射处理泛型的实用建议
反射无法避免，但可以控制风险：
- 永远别对反射结果直接强转泛型类型：把 (List<User>) method.invoke(...) 改成 Object raw = method.invoke(...); if (raw instanceof List) { ... }，再逐个校验元素；
- 配合 TypeReference 或 ParameterizedType 显式传递泛型信息：比如 Jackson 反序列化时不用 objectMapper.readValue(json, List.class)，而用 objectMapper.readValue(json, new TypeReference<List<User>>() {})；
- 封装反射工具类，内置类型校验逻辑：例如写一个 safeCastToList(Class<T> elementType, Object obj) 方法，先检查 obj 是否为 List，再遍历确认每个元素 instanceof elementType，不满足则抛带上下文的 RuntimeException，而非让隐式 cast 晚点崩。
反射不是泛型擦除的替罪羊，而是照出擦除隐患的镜子。问题不在 invoke 这一行，而在它上下游缺失的类型契约。
