原始类型不推荐使用，因其放弃编译期类型安全，导致运行时 classcastexception 难定位；语义模糊、削弱 ide 支持、违背泛型设计初衷，并在反射和框架集成中引发隐性风险。
原始类型（Raw Types）不推荐在现代 Java 开发中使用，核心原因是它主动放弃编译期类型安全，把本该在写代码时发现的问题，推迟到运行时才暴露——而那时错误更难定位、影响更不可控。
编译期检查彻底失效
声明如 List list = new ArrayList(); 后，编译器不再约束你能往里面加什么：
- 可以
list.add("abc")，也可以list.add(new Date())，甚至list.add(null)，全部通过编译 - 取值时返回
Object，强制转型成具体类型（如(String) list.get(0)）成了开发者责任 - 一旦类型不匹配，
ClassCastException在运行时爆发，堆栈里找不到源头，调试成本陡增
语义模糊，掩盖真实意图
原始类型无法表达“这里到底该存什么”：
-
List不说明是字符串列表、用户列表，还是混合对象列表 - 相比
List<string></string>或List>，它既不明确，也不安全，还比通配符更宽松（List>连add()都禁止，天然防污染） - 团队协作中，看到
Map map得靠注释或上下文猜键和值的类型，可读性和可维护性直线下滑
与泛型设计初衷背道而驰
Java 引入泛型的根本目标，就是在编译阶段捕获类型错误。原始类型等于绕开这个机制：
- 泛型不是“锦上添花”，而是类型系统的重要组成部分
- 像
ArrayList<string></string>这样的写法，让 IDE 能高亮错误、自动补全方法、精准跳转，原始类型把这些能力全砍掉了 - 《Effective Java》第26条直接将其比作
goto——不是语法错误，但属于强烈建议规避的代码异味
实际风险远超“能跑就行”
很多看似无害的用法，会在特定路径下触发严重问题：
- 向声明为
List<integer></integer>的集合传入原始类型引用，可能引发“unchecked warning”，而这类警告容易被忽略 - 反射操作中若依赖原始类型判断 Class，可能因泛型擦除导致误判（比如
new ArrayList<string>().getClass() == new ArrayList<integer>().getClass()</integer></string>） - 与现代框架（如 Spring Boot 3+、MyBatis Plus）集成时，原始类型常导致泛型推导失败，引发 Bean 注入异常或 SQL 类型不匹配
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
