Java泛型在运行时被类型擦除，List和List均变为原始类型List，故可通过反射向List添加字符串，但后续强转会抛ClassCastException。
Java 的泛型是编译期机制，运行时通过类型擦除（Type Erasure）统一变为 List（即原始类型），所以**可以利用反射绕过编译检查，在运行时向 List<integer></integer> 中添加字符串**。但要注意：这会破坏类型安全，后续遍历或强转时很可能抛出 ClassCastException。
为什么能绕过？
因为 JVM 在运行时并不知道泛型参数——List<integer></integer> 和 List<string></string> 擦除后都是 java.util.List，其底层存储仍是 Object[]。编译器的泛型检查只发生在编译阶段，反射操作直接调用字节码层面的方法，跳过了编译器校验。
具体操作步骤
通过反射获取 add 方法并调用：
- 创建一个
List<integer></integer>实例（如new ArrayList()） - 使用
getDeclaredMethod("add", Object.class)获取原始add方法（注意不是带索引的重载版本） - 调用
method.invoke(list, "hello")，传入字符串对象
示例代码：
List<Integer> list = new ArrayList<>();
list.add(1);
list.add(2);
try {
Method addMethod = list.getClass().getMethod("add", Object.class);
addMethod.invoke(list, "oops"); // 成功添加字符串
System.out.println(list); // [1, 2, "oops"]
System.out.println(list.get(2)); // "oops" —— 运行时没问题
// 但以下会抛出 ClassCastException！
Integer i = list.get(2); // ❌ java.lang.ClassCastException: String cannot be cast to Integer
} catch (Exception e) {
e.printStackTrace();
}
注意事项和风险
- 仅限测试/调试场景：生产代码中不应依赖此行为，它违背泛型设计初衷
-
遍历时需谨慎：若用增强 for 循环（
for (Integer x : list)），会在取第三个元素时立即报错 - IDE 和编译器无提示：反射调用完全绕过所有静态检查，错误只能在运行时暴露
-
某些集合实现可能有额外防护：比如
Collections.unmodifiableList包装后的列表，反射调用add会直接抛UnsupportedOperationException
替代思路（更安全）
如果真需要混合类型，应显式使用原始类型或泛化容器：
- 用
List<object></object>并手动管理类型 - 自定义封装类，如
class MixedItem { Object value; Class> type; } - 使用
Map<string object></string>或 JSON 结构临时承载异构数据
不复杂但容易忽略：泛型不是运行时契约，而是编译器给你的“善意提醒”。反射能跳过去，代价是把风险留给运行时。
