Java编程高频的“踩坑点”-01：fastjson.JSON 转换时泛型擦除问题

(一)Java 泛型擦除（Type Erasure）

Java 泛型擦除（Type Erasure）是 Java 泛型的一种底层实现机制。

它的核心含义是：Java 的泛型只在编译阶段生效，一旦代码编译成字节码（.class 文件），所有的泛型类型信息都会被"擦除"掉，JVM 在运行时根本不知道泛型的存在。

简单来说，泛型就像是 Java 编译器提供的一层"语法糖"或"伪装"，它能帮你在写代码时做好类型检查，但到了程序真正跑起来的时候，这层伪装就被撕掉了。

01，🤔 为什么要设计泛型擦除？

核心原因是为了向下兼容 。

泛型是在 Java 5 版本才引入的。为了让使用了泛型的新代码，能够完美兼容 Java 5 之前没有泛型的老代码和老类库，同时保证旧的 JVM 不需要做任何修改就能运行新的泛型代码，Java 设计者选择了这种"编译期检查 + 运行期擦除"的折中方案。

02，⚙️ 泛型擦除是如何工作的？

编译器在编译代码时，会遵循以下两条核心规则进行"擦除"：

无界泛型擦除为 Object ：如果泛型没有指定边界，就会被替换成 Object。
有界泛型擦除为上界 ：如果泛型指定了边界（例如 <T extends Number>），就会被替换成它的边界类型（即 Number）。

03， 🤔 举个直观的例子：

假设你在代码中写了这样一个泛型集合：

java 复制代码

List<String> list = new ArrayList<>();

list.add("hello");

String s = list.get(0);

经过编译器处理并擦除泛型后，实际生成的字节码逻辑等同于：

java 复制代码

// 泛型 <String> 被擦除，变成了原始类型 List
List list = new ArrayList(); 

list.add("hello");

// 编译器自动插入了强制类型转换 (String)
String s = (String) list.get(0);

也就是说，编译器在帮你做完类型检查后，自动把泛型拿掉，并在取值的地方悄悄帮你加上了强制类型转换。

04，⚠️ 泛型擦除带来的常见限制

正是因为运行时泛型信息已经不存在了，所以 Java 中会出现一些看似奇怪的限制：

无法通过 instanceof 判断泛型类型
因为运行时没有泛型信息，所以 if (obj instanceof List<String>) 这种写法是非法的，编译器会直接报错。你只能判断 if (obj instanceof List)。
不能直接创建泛型数组
正如我们之前聊到的，new List<String> 是不允许的。因为数组在运行时需要知道确切的元素类型来做安全检查，而泛型擦除后 JVM 无法得知具体的泛型类型。
不能直接实例化泛型对象
代码中不能写 new T()。因为编译后 T 已经被擦除成了 Object 或某个上界，JVM 根本不知道 T 具体是哪个类，也就无法进行实例化。
无法重载仅泛型参数不同的方法
例如下面两个方法，编译后它们的参数都会变成 List，方法签名完全一致，因此无法构成重载：java

编辑
java 复制代码
```
void process(List<String> list) {}

 // 编译报错
void process(List<Integer> list) {}
```

总结一下： Java 泛型擦除是为了兼容老版本而做出的妥协。

它把类型安全检查的工作全部交给了编译器，从而保证了运行时的效率和兼容性，但也因此带来了一些使用上的限制。这也正是为什么在 Fastjson 等框架反序列化时，必须通过 TypeReference 这种特殊手段来"绕过"擦除，从而保留住泛型信息。

（二），Fastjson泛型擦除"踩坑点"

在使用 com.alibaba.fastjson.JSON（包括 Fastjson 1.x 和 Fastjson2）进行转换时，泛型擦除是一个非常经典且高频的"踩坑点"。

在实际业务开发中，泛型擦除引发以下几个典型的严重问题：

1. 嵌套泛型对象的反序列化类型丢失

在微服务或前后端交互中，我们通常会定义一个统一的响应包装类，比如 Result<T> 或 Response<T>。当 T 本身又是一个泛型对象时，极易出错。

问题场景：

java 复制代码

public class Result<T> {
    private int code;
    private T data;
}

// 期望反序列化为 Result<List<User>>
String json = "{\"code\":200,\"data\":[{\"id\":1,\"name\":\"张三\"}]}";

// ❌ 错误写法：泛型信息丢失
Result wrongResult = JSON.parseObject(json, Result.class);

// 此时 wrongResult.getData() 的实际类型会变成 JSONObject 或 LinkedHashMap，
// 后续如果直接强转或遍历，会抛出 ClassCastException。

解决方案：
使用 **TypeReference**来保留完整的嵌套泛型签名，保留泛型信息，安全、正确地获取强类型的 List 集合。

java 复制代码

// ✅ 正确写法
Result<List<User>> correctResult = JSON.parseObject(json, 
                    new TypeReference<Result<List<User>>>(){});

// 安全获取到具体的 User 对象列表
List<User> users = correctResult.getData();

机制原理：

巧妙利用匿名内部类保留类型信息， new TypeReference<List<User>>() {}这种写法（注意末尾的大括号 {}）实际上是创建了一个继承自 TypeReference 的匿名内部类 。

虽然 Java 会擦除普通变量的泛型，但类的继承关系和泛型参数会被保留在编译后的字节码中 。Fastjson 在底层通过 Java 的反射机制，能够从这个匿名子类中提取出完整的泛型结构（即知道这是一个包含 **User**的 List），从而精准地把 JSON 数据还原成你需要的对象。

2. 运行时 instanceof 判断失效

由于泛型在编译后会被擦除，JVM 在运行时根本感知不到 `<String>` 或 `<Integer>` 的区别，因此不能直接对泛型进行 `instanceof` 检查。

问题代码：

java 复制代码

List<String> list = new ArrayList<>();

// ❌ 编译直接报错：
//  Cannot perform instanceof check against parameterized type List<String>
if (list instanceof List<String>) { 
    // ...
}

解决建议：

在运行时只能检查原始类型，例如使用 list instanceof List<?> 或 list instanceof List。

3. 无法创建泛型数组

同样是因为类型擦除，Java 不允许直接初始化带有泛型参数的数组。

问题代码：

java 复制代码

// ❌ 编译报错：Cannot create a generic array of List<String>

List<String>[]  stringListArr = new List<String>[] ;

解决建议：

通常建议使用 List<List<String>> 来代替泛型数组，或者先创建原始类型数组再进行强转（但不推荐，存在安全隐患）。

4. 动态泛型的高级处理（反射场景）

如果你是在写通用的工具类、RPC 框架解码器或 DAO 层，泛型的类型往往是在运行时通过参数动态传递的，这时无法直接写死 new TypeReference<...>。

解决方案：

可以使用 Fastjson 提供的 ParameterizedTypeImpl 手动构建泛型类型：

java 复制代码

public <T> List<T> parseList(String json, Class<T> elementClass) {

    // 手动构建 List<T> 的完整类型信息
    Type listType = new ParameterizedTypeImpl(new Type[]{elementClass},
                                         null, List.class);

    return JSON.parseObject(json, listType);
}

这样在调用 parseList(jsonStr, User.class) 时，就能在动态场景下完美避开泛型擦除的坑。

总结一下：

只要涉及到 Fastjson 的反序列化（parseObject / parseArray），并且目标对象带有泛型（无论是 List<T>、Map<K,V> 还是自定义的 Result<T>），千万不要直接传 .class ，一定要通过 TypeReference 或 **ParameterizedTypeImpl**把完整的泛型结构"喂"给 Fastjson，这样才能从根本上杜绝类型转换异。

通过 TypeReference 这种特殊手段来"绕过"擦除，从而保留住泛型信息。