TypeToken 能解决泛型擦除后的类型获取问题，核心在于“把泛型信息固化到类定义中”，而不是依赖运行时对象本身——因为对象实例在 JVM 中确实不携带泛型类型。
为什么直接反射拿不到泛型实际类型
Java 编译时会执行类型擦除：List<String> 编译后变成原始的 List，getClass() 返回的是 List.class，不是 List<String>.class。字段、方法签名里保留的泛型信息（比如 private List<User> users）可通过反射读取，但 new ArrayList<String>() 这样的实例，反射完全无法还原 String。
关键点：
泛型信息只存在于源码、字节码签名、类结构（如父类/接口声明、字段类型、方法返回值）中 普通对象实例不存储泛型参数，getClass().getTypeParameters() 拿到的是形参 T，不是实参 String ParameterizedType 是反射中承载泛型信息的主要接口，但必须有“载体”才能访问 getActualTypeArguments()
TypeToken 的工作原理：靠匿名子类“存下”泛型
TypeToken 不是魔法，它利用了 Java 类加载时对父类泛型签名的保留机制。当你写：
new TypeToken<Map<String, Integer>>() {}
大括号创建了一个匿名子类，JVM 会把这个子类的父类签名 Map<String, Integer> 记录进其常量池。之后调用 getType()，内部通过 getClass().getGenericSuperclass() 取出这个 ParameterizedType，再调用 getActualTypeArguments() 就能拿到 String 和 Integer 对应的 Type 实例。
注意几个硬性条件：
必须是匿名子类写法，不能赋值给变量再传入（局部变量引用会丢失泛型上下文） 不能用泛型方法包装 TypeToken 构造（比如 <T> TypeToken<T> create(Class<T> c)），那样 T 仍是 TypeVariable，无法解析 getType() 返回的是 Type 接口，若需 Class，得用 TypeToken.getRawType() 或手动判断并转换
典型使用场景与写法
最常见的用途是 JSON 反序列化、泛型集合注入、类型安全的容器构建。
例如 Gson 解析嵌套泛型列表：
new TypeToken<List<OrderItem>>() {}.getType()
又比如判断两个泛型类型是否等价（比 instanceof 更精确）：
new TypeToken<List<String>>() {}.equals(new TypeToken<ArrayList<String>>() {}) —— 返回 true，因为 TypeToken 关注的是逻辑类型，不是具体实现类
再比如配合泛型工厂做类型推导：
public <T> T fromJson(String json, TypeToken<T> token) { return gson.fromJson(json, token.getType()); }
替代方案对比：什么时候不用 TypeToken
TypeToken 强大但有局限：它只适用于编译期已知的泛型结构。如果类型来自配置、运行时拼接或用户输入，它就无能为力。
可考虑的其他方式：
字段反射：适合框架扫描成员变量，如 private Map<Long, User> cache; 父类泛型继承：适用于基类抽象 + 子类固化，如 abstract class Dao<T> { protected final Class<T> entityClass; } Kotlin 的 reified：在 Kotlin 中更简洁，内联函数 + reified 可直接用 T::class 显式传 Class：简单直接，但无法表达嵌套泛型（如 List<Map<K,V>>）
评论(0)