Java泛型在运行时被擦除，无法直接用instanceof或反射断言泛型类型参数，但可通过编译期约束验证、反射提取ParameterizedType（限可保留场景）、行为断言替代类型断言、以及注解处理器校验等间接方式保障类型安全。
Java 泛型本身在运行时被擦除，所以不能直接用 instanceof 或反射断言泛型类型参数（如 list instanceof List<String> 是语法错误且编译不通过）。但单元测试中仍可通过几种**间接但类型安全**的方式验证泛型行为是否符合预期。
利用泛型类的构造与编译期约束做“静态防御”
泛型真正的类型安全发生在编译阶段。只要测试代码能成功编译，就说明泛型使用是合法的——这是最基础、最可靠的“类型安全断言”。
- 写一个
List<String>，尝试添加Integer：编译失败即证明泛型约束生效 - 写一个泛型方法
<T> T getFirst(List<T> list)，传入List<Double>并接收为Double d = getFirst(...)：若编译通过，说明类型推导正确 - 这类“编译即测试”的思路常用于构建型测试或 CI 中的编译检查环节
用反射提取 ParameterizedType 验证泛型声明（仅限可保留场景）
虽然泛型信息被擦除，但在某些上下文中（如继承带泛型的父类、匿名内部类、字段/方法签名），泛型类型信息可通过反射获取。适用于验证自定义泛型容器或泛型工具类的类型元数据。
deep-java-review
下载
Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...
- 例如：定义
class StringList extends ArrayList<String> {}，可用StringList.class.getGenericSuperclass()获取ParameterizedType，再调用getActualTypeArguments()得到String.class - JUnit 5 中可封装成辅助断言：
assertGenericType(StringList.class, ArrayList.class, String.class) - ⚠️ 注意：局部变量、方法返回值、普通实例对象无法通过反射还原泛型类型
通过行为断言替代类型断言
不直接验证“是不是 List<String>”，而是验证“它表现得像 List<String>”——这是更务实、更健壮的测试方式。
立即学习“Java免费学习笔记（深入）”；
- 向泛型集合添加非法类型（如
list.add(123)）应触发编译错误（非运行时）；若你测试的是运行时泛型工具（如 JSON 反序列化器），则断言反序列化后get(0)的实际类型是String.class - 对泛型方法传入
String[]，断言返回值可安全赋给String变量，且调用.length()不报错 - 用
assertThat(actual).isInstanceOf(String.class)（AssertJ）验证单个元素类型，而非整个集合泛型
结合注解 + 泛型处理器做编译期校验（高级场景）
在框架或 SDK 开发中，可借助注解处理器（Annotation Processor）在编译期扫描泛型使用，并生成错误提示。单元测试可模拟该过程，验证注解+泛型组合是否触发预期检查。
- 例如：定义
@ValidateType(String.class)注解，配合泛型接口Handler<T>，注解处理器检查实现类是否满足T约束 - 测试时调用
javac -processor MyProcessor编译含违规泛型的测试类，断言其输出包含指定错误信息 - 这属于“测试编译器行为”，适合基础设施类库的质量保障
