Java泛型类型检查发生在编译期，运行时已擦除；验证方式是构造非法代码（如List<String> add(42)）观察编译报错，而非运行时测试，核心价值在于将错误提前至编译阶段拦截。
Java 泛型的类型检查发生在编译期，运行时已擦除，所以“测试编译期检查”本质上是**通过尝试写出非法代码，观察编译器是否报错**——而不是写个单元测试去“运行”它。关键在于：让编译器暴露类型不匹配，从而验证泛型约束是否生效。
直接写非法调用，看编译是否失败
这是最直接、最可靠的验证方式。泛型的核心价值就是把错误拦在编译阶段，因此你只需构造一个明显违反泛型声明的操作，确认它无法通过 javac 编译即可。
- 声明
List<String>，然后调用add(42)或add(new Date())→ 编译报错（如 “no suitable method found for add(int)”） - 声明
Map<Integer, String>，然后写map.put("key", "value")→ 编译报错（key 类型不匹配） - 声明
Function<String, Integer>，然后传入(Double d) -> d.intValue()→ 编译不通过（函数签名不兼容）
对比无泛型场景，凸显编译期优势
写两段等价逻辑：一段用原始类型（raw type），一段用泛型。你会发现只有泛型版本能在编译时捕获问题。
- 原始类型：
List list = new ArrayList(); list.add("ok"); list.add(1); String s = (String) list.get(1);→ 编译通过，但运行时抛ClassCastException - 泛型版本：
List<String> list = new ArrayList<>(); list.add(1);→ 编译直接报错，根本不会生成 class 文件
这种对比能清晰说明：泛型不是“多加一层运行时校验”，而是让错误从 运行时崩溃 提前到 编译失败，大幅降低排查成本。
立即学习“Java免费学习笔记（深入）”；
利用 IDE 实时反馈作为辅助验证
现代 IDE（如 IntelliJ IDEA、Eclipse）会在编辑时高亮泛型违规操作，并给出准确错误提示，这本身就是编译期检查的前端体现。
- 输入
list.add(后，IDE 会自动提示可接受的参数类型（仅String），并阻止补全非匹配类型 - 将鼠标悬停在泛型变量上，可看到实际推断出的类型（如
List<String>），确认类型参数已被正确识别 - 故意删掉泛型声明（如写成
List list），IDE 通常会标黄警告：“Raw use of parameterized class 'List'”
注意：反射或类型擦除相关的“绕过”不属于正常测试范畴
像用 List rawList = new ArrayList<String>(); rawList.add(1); 这类写法虽然能编译通过，但它主动放弃了泛型保护，属于反模式。这不是在“测试泛型检查”，而是在测试“如何破坏它”。真正的测试目标是确认：只要按规范使用泛型，编译器就会守好类型关卡。
