TypeToken能解决泛型擦除问题，核心是利用匿名子类将泛型信息固化到类定义中；因JVM运行时对象实例不携带泛型参数，而编译后List<String>被擦除为List，getClass()只能返回List.class，无法还原String。
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>>）
