原始类型与泛型混用本质是类型契约断裂，需通过 -Xlint:unchecked 定位问题，按声明、返回值、字段分场景修复，禁用 unchecked 强转和 @SuppressWarnings，最终验证编译报错与去强转。
原始类型（Raw Type）和泛型混用，本质是类型契约断裂——一边声明“我只管Object”，一边又期望“你给我String”。这种写法不会立刻报错，但会在编译期触发 unchecked 警告，运行时埋下 ClassCastException 隐患。处理核心不是绕开警告，而是让类型从声明、传递到使用全程一致。
定位问题源头
先用编译器把隐患揪出来：
- 加参数
-Xlint:unchecked编译，所有原始类型使用点都会标出具体位置 - 重点关注：集合变量声明（
List list = new ArrayList();）、方法返回值（public List getNames() { ... }）、泛型类字段（private Map cache;） - IDE 中启用 “Raw use of parameterized class” 检查（IntelliJ 默认 warning，可设为 error）
分场景修复策略
不能一刀切补 ，得看上下文实际语义：
- 构造器调用（如
new ArrayList()）：优先用菱形语法new ArrayList；若类型不明确，先用() >占位，再顺藤摸瓜找源头 - 方法返回原始类型：查该方法的调用处——如果每次取的都是字符串，就改返回
List；如果是工具类通用方法，考虑加泛型参数List toList(...) - 对接老框架 API（如旧版 MyBatis 的
selectList(String)返回List）：不直接强转，封装适配层，加校验逻辑或显式传入Class
避免危险操作
有些做法看似“能过编译”，实则放弃安全底线：
- 别滥用
@SuppressWarnings("unchecked")，除非已做元素类型遍历校验并有单元测试覆盖 - 别用
(String[]) list.toArray()这种 unchecked cast，改用list.toArray(new String[0]) - 别在 public 方法签名里暴露原始类型，哪怕加了
@Deprecated也不推荐；应提供泛型重载
验证是否真正修复
修复完成不是看警告没了，而是确认类型约束生效：
- 尝试往刚泛型化的集合里加错误类型（如向
Listadd("abc")），必须编译失败 - 检查所有
get()调用是否不再需要手动强转 - 用 IDE 的 “Find Usages” 扫描整个项目，特别注意 test、config、DTO 类中易被忽略的原始类型字段
