typetoken能解决泛型擦除问题，核心是利用匿名子类将泛型信息固化到类定义中；因jvm运行时对象实例不携带泛型参数，而编译后list被擦除为list，getclass()只能返回list.class，无法还原string。

TypeToken 能解决泛型擦除后的类型获取问题，核心在于“把泛型信息固化到类定义中”，而不是依赖运行时对象本身——因为对象实例在 JVM 中确实不携带泛型类型。

为什么直接反射拿不到泛型实际类型

Java 编译时会执行类型擦除：List 编译后变成原始的 List，getClass() 返回的是 List.class，不是 List.class。字段、方法签名里保留的泛型信息（比如 private List users）可通过反射读取，但 new ArrayList() 这样的实例，反射完全无法还原 String。

关键点：

• 泛型信息只存在于源码、字节码签名、类结构（如父类/接口声明、字段类型、方法返回值）中
• 普通对象实例不存储泛型参数，getClass().getTypeParameters() 拿到的是形参 T，不是实参 String
• ParameterizedType 是反射中承载泛型信息的主要接口，但必须有“载体”才能访问 getActualTypeArguments()

TypeToken 的工作原理：靠匿名子类“存下”泛型

TypeToken 不是魔法，它利用了 Java 类加载时对父类泛型签名的保留机制。当你写：

new TypeToken

大括号创建了一个匿名子类，JVM 会把这个子类的父类签名 Map 记录进其常量池。之后调用 getType()，内部通过 getClass().getGenericSuperclass() 取出这个 ParameterizedType，再调用 getActualTypeArguments() 就能拿到 String 和 Integer 对应的 Type 实例。

注意几个硬性条件：

• 必须是匿名子类写法，不能赋值给变量再传入（局部变量引用会丢失泛型上下文）
• 不能用泛型方法包装 TypeToken 构造（比如 TypeToken create(Class c)），那样 T 仍是 TypeVariable，无法解析
• getType() 返回的是 Type 接口，若需 Class，得用 TypeToken.getRawType() 或手动判断并转换

典型使用场景与写法

最常见的用途是 JSON 反序列化、泛型集合注入、类型安全的容器构建。

例如 Gson 解析嵌套泛型列表：

new TypeToken>() {}.getType()

又比如判断两个泛型类型是否等价（比 instanceof 更精确）：

new TypeToken>() {}.equals(new TypeToken>() {}) —— 返回 true，因为 TypeToken 关注的是逻辑类型，不是具体实现类

再比如配合泛型工厂做类型推导：

public T fromJson(String json, TypeToken token) { return gson.fromJson(json, token.getType()); }

替代方案对比：什么时候不用 TypeToken

TypeToken 强大但有局限：它只适用于编译期已知的泛型结构。如果类型来自配置、运行时拼接或用户输入，它就无能为力。

可考虑的其他方式：

• 字段反射：适合框架扫描成员变量，如 private Map cache;
• 父类泛型继承：适用于基类抽象 + 子类固化，如 abstract class Dao { protected final Class entityClass; }
• Kotlin 的 reified：在 Kotlin 中更简洁，内联函数 + reified 可直接用 T::class
• 显式传 Class：简单直接，但无法表达嵌套泛型（如 List