反射能往List<String>里塞Integer，是因为泛型仅存在于编译期，运行时已被擦除为ArrayList和add(Object)，JVM不校验泛型约束；插入不报错，但取值时强转失败抛ClassCastException，错误延迟爆发且堆栈难追溯。
反射能往 List<String> 里塞 Integer，不是因为它“高明”，而是因为 JVM 根本不认泛型——擦除后只剩 ArrayList 和 add(Object)。风险不在插入那一刻，而在后续取值、遍历或序列化时突然崩掉，且堆栈远离问题源头，极难定位。
为什么插入不报错，用的时候才出事
泛型只是编译期语法糖，运行时 List<String> 和 List<Integer> 都是 ArrayList，底层是 Object[]。反射调用 add(Object) 方法完全合法，JVM 只检查参数是不是 Object 子类，不关心你声明过什么泛型。
-
list.add("ok")和add.invoke(list, 42)在字节码层面一模一样 - 真正出错发生在
String s = list.get(1)：JVM 返回Object，编译器悄悄插入(String)强转，Integer转不了String，抛ClassCastException - 如果是 JSON 序列化，可能表现为字段错乱、空值、下游解析失败，但日志里找不到异常堆栈
典型症状与快速定位线索
这类问题不会立刻崩溃，常表现为“假死”或间歇性异常：
- CPU 持续偏高，
jstack -l显示大量线程卡在ArrayList.get、ReferencePipeline.forEach或 Jackson 的BeanDeserializer.deserialize - 接口返回 JSON 字段缺失、类型错位（如
"id": {}或"name": 123），但 controller 层没抛异常 - 日志里有
WARN级的JsonMappingException、ArrayStoreException，或被吞掉的ClassCastException - 某个集合字段（如
data、items、resultList）在不同请求中元素类型不一致
怎么找到那个偷偷塞错对象的反射点
别盲目查所有反射，聚焦三类高危模式：
立即学习“Java免费学习笔记（深入）”；
- 全局搜索：
getDeclaredMethod.*add|set|put、getMethod.*Object.class、invoke.*\d+|\w+（含数字或变量参数）、Field.setAccessible(true)+ 泛型字段名（如records、payload） - 重点审查工具类：自定义
BeanUtils、JSON 转换器、DAO 封装层，尤其入参是Map<String, Object>或Object...的方法 - 写最小单元测试验证：往
List<String>用反射塞new Date()，再执行for (String s : list)，看是否真能过编译却运行时报错
生产环境临时止血与长期防御
线上不能停机改代码，先用轻量手段确认并收敛风险：
- Arthas
watch拦截关键集合的add方法：watch com.example.OrderService items 'params[0].getClass()' -x 3，实时看谁往里面塞了非预期类型 - 加运行时校验：对核心集合封装一层，
add(T)中用elementType.isInstance(e)检查，不通过直接抛异常（比事后崩溃好排查） - 禁用原始类型：IDE 设为 error 级警告，杜绝
List list = new ArrayList()；JSON 反序列化必须用TypeReference，不用List.class - CI 加字节码扫描：用 SpotBugs 或自定义规则检测裸
@SuppressWarnings("unchecked")、无Class参数的泛型转换工具方法
