Java泛型是编译期伪泛型，运行时类型擦除，仅靠编译检查和隐式转换保障安全；原始类型、反射、@SuppressWarnings或通配符误用等会绕过检查，导致ClassCastException在运行时发生。
Java泛型在编译期做类型检查，运行时已擦除，所以它不能阻止所有类型错误——比如通过反射或原始类型绕过检查时，ClassCastException仍可能在运行时抛出。
泛型的类型检查发生在编译期
Java泛型是“伪泛型”，底层靠类型擦除实现。编译器看到 List，会检查所有 add()、get() 调用是否符合 String 约束，并插入隐式类型转换（如把 get(0) 的返回值自动转为 String）。
但擦除后，JVM 实际只认 List（原始类型），不保留泛型信息。
- 使用
javap -c查看字节码，能看到checkcast指令被自动插入在get()后面 - 若用
@SuppressWarnings("unchecked")强制绕过编译检查，或用反射调用add()插入非String对象，运行时才暴露问题 - 泛型无法约束数组创建（
new T[10]不合法），因为类型信息在运行时不存在
原始类型（raw type）是泛型安全的最大破口
一旦把泛型集合赋给原始类型变量，编译器就放弃所有类型检查：
立即学习“Java免费学习笔记（深入）”；
Listlist = new ArrayList<>(); List raw = list; // 编译通过，但危险 raw.add(123); // 编译通过！实际存入 Integer String s = list.get(0); // 运行时报 ClassCastException
这种写法常见于遗留代码或误用 API（如某些老框架返回 List 而非 List）。
- 永远避免显式声明原始类型变量（如
List raw） - 启用
-Xlint:unchecked编译选项，让编译器对原始类型使用发出警告 - IDE（如 IntelliJ）默认高亮原始类型使用，别忽略这些提示
通配符与边界如何影响类型安全性
? extends T 和 ? super T 不是“更松”的泛型，而是对读/写能力做了精确限制，反而提升了类型安全：
-
List extends Number>：可安全读出Number及其子类，但不能add()任何具体类型（除了null），防止破坏协变一致性 -
List super Integer>：可安全写入Integer或其子类，但读出只能当Object处理 - 错用
add()在extends通配符上（如list.add(new Double(1.0))）会被编译器直接拒绝
真正容易被忽略的是泛型方法中类型参数的推断失效场景——比如传入 null 或泛型擦除后的数组，会导致编译器无法推导 T，进而放宽检查。这时候，ClassCastException 就藏在看似干净的代码后面。
