java泛型在运行时仅保留原始类型，类型擦除是为兼容旧jvm的设计选择；隐式强制转换由编译器插入，若运行时对象类型不匹配则抛classcastexception，需通过禁用原始类型、使用上界通配符、运行时校验及typetoken等机制主动防御。
Java 泛型在历史遗留代码中混用原始类型（Raw Types），本质不是“兼容”，而是把类型安全让渡给运行时——表面能跑，实际埋雷。关键不在能不能写通，而在编译期防线是否还立得住。
原始类型为何会“看似兼容”
原始类型（如 List、Map）是泛型擦除后的退化形态，编译器对它不做类型检查，所以老代码调用新泛型方法、或新代码接收旧 API 返回的原始集合时，语法上不报错。但这只是编译器“放行”，不是类型契约成立：
- 向 List 加 String 和 File 都通过编译，但后续取值时强转就可能崩
- 把返回 List 的旧工具方法结果赋给 List
，等于把没验过的数据直接塞进强类型链路 - 泛型方法如
T parse(Object) 被当成原始调用，T 的推导失效，返回值变 Object
真正危险的混合场景
不是所有 raw type 写法都一样危险，以下三类最常引发 ClassCastException 或逻辑错乱：
- 声明即退化：比如 List list = new ArrayList(); 后续所有 add / get 操作都失去约束
-
跨层传递未校验：JSON 解析器返回 Map，你直接 (Map
) 强转，但 JSON 字段名或嵌套结构稍有偏差，运行时才暴露 -
泛型嵌套丢失：像 Pair p : list（其中 list 是 List
>> ），因 p 是原始类型，p.getValue1() 被当 Object，无法调用 size() 或 get(0)
过渡期该怎么做才安全
不靠压制警告，也不靠盲目强转，核心是“收口 + 校验 + 显式”：
- 对外提供 @Deprecated 的原始类型重载方法（如 getDataRaw()），但内部立刻包装成泛型容器：new ArrayList(rawList) 或流式过滤
- 接收原始类型输入时，遍历检查每个元素：if (!(o instanceof User)) throw new IllegalArgumentException(...)
- 必须桥接第三方库时，封装适配方法并显式传入 Class
： List toTyped(List> raw, Class type) - 反射调用泛型方法，用 Method.getGenericReturnType() 获取真实签名，别依赖 getClass()（它只返回擦除后的原始类型）
怎么确认真的修好了
消除 unchecked 警告只是第一步。验证是否真安全，看三点：
- 尝试往已声明 List
的集合里加字符串字面量，必须被编译器拦截（报错，不是警告） - 全局搜索 List、Map、Set 等原始写法，确保没有漏网之鱼
- 所有 @SuppressWarnings("unchecked") 必须紧贴具体语句，且附带注释说明：为什么可信、校验在哪、测试覆盖在哪
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
