泛型在编译期帮助发现错误，但混入原始类型后，错误可能拖到读取元素时才暴露。
本文使用JDK 7，示例为方法体或类定义片段。源码学习需要区分语言规则、公共接口约定与某个版本的实现。本文把讨论范围固定在 Java 7，不把后续版本的集合结构或语法写进来。
1. 从现象推到机制
Java 的泛型主要通过擦除实现，运行时的普通 List 不保存每个类型参数的完整约束。编译器会在需要的位置插入强制转换。原始类型写入绕过静态检查后，读成 String 就可能发生类型转换异常。
图中的四个节点分别表示参数化声明、原始类型、类型擦除、读取转换。顺着实线检查输入如何变成输出，再沿虚线核对反馈条件。图示表达的是本文讨论的关系，不是实测曲线或现场截图。
2. 最小实现与输入条件
在独立示例中故意把参数化列表交给原始引用，保留编译警告。编译警告正是缺口所在，不能通过压制警告把问题当作解决。
1
2
3
4
List<String> names = new ArrayList<String>();
List raw = names;
raw.add(Integer.valueOf(7));
String first = names.get(0); // ClassCastException
将片段放入独立的小工程，补齐 imports（导入声明）和调用入口。观察返回值、异常类型及对象状态；并发实验需要重复交错，单次没有出错不能证明线程安全。
3. 用对照区分原因
下表列出需要主动改变的条件。预期行为来自机制分析，复现时还需记录运行环境和原始输出，不能将预期当作已经测得的结果。
| 改变的条件 | 需要验证的行为 |
|---|---|
| 只用参数化引用写入 | 错误类型在编译期被拒绝 |
| 通过原始类型写入整数 | 读取时可能发生类型转换异常 |
| 比较不同参数的列表类 | 运行时类可以相同 |
对照 1：只用参数化引用写入
错误类型在编译期被拒绝。观察时记录编译器的类型检查位置。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 2：通过原始类型写入整数
读取时可能发生类型转换异常。观察时记录警告与插入转换的语句。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
对照 3：比较不同参数的列表类
运行时类可以相同。观察时记录参数化类型与 Class 的区别。把这个条件与基准情形分开，有助于判断变化来自哪一层；若得到相反结果，应先核对前提，再修改实现。
4. 适用条件与取舍
泛型数组、通配符和反射中的类型信息各有边界。不要从“存在擦除”推断所有泛型元信息都消失，也不要用运行时类判断代替元素验证。
一次正常运行只覆盖了这组输入。继续扩展前，应把上面的异常对照保留下来，尤其关注“比较不同参数的列表类”这一分支。后续方案若改变了图中任意一处依赖，原来的判断就要重新验证，不能仅凭界面相似或返回值相同沿用结论。
