Java泛型通过编译期强约束保障类型安全，而非运行时检查：add()仅接受指定类型，get()自动返回正确类型无需强转，遍历元素类型已确定；类型擦除后仍靠编译器插入校验，反射误操作会在运行时立即抛ClassCastException。
Java 泛型在集合中通过编译期强约束与运行时隐式保障双层机制实现类型安全，核心不是靠运行时检查，而是把错误拦截在写代码阶段。
编译时就卡死非法操作
声明如 List<string></string> 后，编译器会全程跟踪类型使用：
- 调用
add()时，只接受String或其子类，传入Integer、File等直接报错，不生成字节码 - 调用
get()时，返回值被自动视为String，无需(String)强转，也不存在强转失败的可能 - 遍历（如增强 for 循环或
Iterator.next()）拿到的每个元素，类型已由泛型确定，直接当String用
类型擦除不等于放弃安全
虽然泛型信息在运行时被擦除（List<string></string> 和 List<integer></integer> 运行时都是 List），但安全不依赖运行时保留类型：
- 擦除后底层仍用
Object存储，但所有“出入”路径都被编译器插入了隐形类型校验 - 比如通过反射强行塞入错误类型，后续调用
get()时，编译器生成的自动转型代码会在运行时立刻抛ClassCastException，问题仍能暴露 - 桥接方法（bridge method）确保继承/实现泛型接口时，重写方法的参数和返回值仍受类型约束
对比非泛型集合的脆弱性
没有泛型时，List 实际是 List<object></object> 的退化形态：
立即学习“Java免费学习笔记（深入）”；
- 存数据无限制：
list.add("ok"); list.add(42); list.add(new Date());全部编译通过 - 取数据必强转：
String s = (String) list.get(1);—— 运行到这儿才崩，调试困难 - IDE 和静态分析工具完全无法预警，错误潜伏在测试覆盖不到的分支里
真正起作用的是开发者习惯+编译器配合
泛型本身不会自动修复逻辑错误，但它强制形成一种安全习惯：
- 声明即契约：看到
Map<long user></long>就明确键是ID、值是用户对象 - 减少样板代码：不用写一堆
(User)，降低手误概率 - 提升可读性与协作效率：别人读你的
Queue<requesttask></requesttask>，立刻理解用途，无需翻注释或源码
