泛型集合能避免ClassCastException是因为类型检查提前到编译期，运行时不会出现类型不匹配；add和get操作均受类型约束，且类型擦除不影响编译期安全。
泛型集合为什么能避免 ClassCastException
因为类型检查被提前到了编译期，运行时根本不会出现“本该是 String 却塞进来了 Integer”这种问题。
常见错误现象：list.get(0) 返回 Object，你硬转成 String，结果实际存的是 Double —— 运行时报 ClassCastException。
- 用
List<string></string>后，add(123)直接编译失败，不让你写错 -
get()方法返回值类型就是String，不用写(String) list.get(0) - 类型信息只在编译期起作用，字节码里仍是
Object（类型擦除），所以旧代码仍能调用新泛型类
什么时候必须用泛型集合，而不是裸 List
只要你需要明确知道集合里“只能装什么”，就该用泛型。不是“可选”，是“应该默认开启”。
使用场景：
- DAO 层返回
List<user></user>，而不是List：下游不用猜、不用试、不会错转型 - 方法参数接收
Map<string integer></string>：调用方传Map<string date></string>会立刻报错 - Stream 操作链中，
stream().map(...).collect(Collectors.toList())的推断依赖泛型，否则可能推成List<object></object>
T、E、K/V 这些占位符到底怎么选
不是随便起的缩写，是约定俗成的语义标签，影响可读性，也影响 IDE 推断和框架识别（比如 Spring Data JPA 的 Repository<t id></t>）。
-
E专用于集合元素（ArrayList<e></e>、Queue<e></e>） -
T是最通用的类型参数，适合工具类或容器类（Result<t></t>、Box<t></t>） -
K/V必须成对出现在Map及其子接口中（HashMap<k v></k>） - 别用
A、B或中文拼音，IDE 不会友好提示，团队协作时容易误解
泛型集合真能提升性能吗
直接效果几乎为零 —— 编译后还是 Object 操作，没有额外字节码优化。但间接收益明显：避免了装箱/拆箱和强制转换开销。
- 比如
List<integer></integer>在循环中取值，get(i)返回的就是Integer，无需再转型；而裸List要写(Integer) list.get(i)，多一次类型检查 + 强制转换 - 更关键的是：
int存进List<integer></integer>会自动装箱，这不是泛型带来的开销，而是包装类本身决定的；想免装箱得用第三方库（如 Eclipse Collections）或原始类型特化（如IntList） - 泛型本身不加速，但它让“写对代码”变得更容易，从而减少调试、规避反射绕过类型检查等高危补救手段
ClassCastException 才意识到，那个红色波浪线（编译错误）其实是最好的帮手。 
