GenericSignatureFormatError是JVM加载类时因泛型Signature属性非法抛出的ClassFormatError子类，根源在于混淆工具（如ProGuard/R8）未保留Signature等关键属性，导致反射获取泛型信息失败；需配置-keepattributes Signature等规则修复。
类型擦除本身是编译阶段的固定行为，与混淆无关；真正影响泛型签名完整性的，是代码混淆工具（如ProGuard、R8、D8）对类名、方法名、字段名及Signature属性的处理方式。混淆默认会压缩、重命名甚至移除这些元数据，导致原本可通过反射获取的泛型信息丢失——这不是类型擦除“被破坏”，而是附加签名信息被主动删减。
混淆为何会“吃掉”泛型信息
Java字节码中，泛型类型信息不存于类主体，而是以Signature属性形式附加在类、字段、方法上。例如：
– class List 的泛型父类信息存在Signature属性中；
– public 的方法签名也依赖该属性。
混淆工具若未保留这些属性，反射调用getGenericSuperclass()或getGenericReturnType()就会返回原始类型（如Object），而非真实泛型结构。
关键保留规则（以R8/ProGuard为例）
-
必须保留
Signature属性：添加规则-keepattributes Signature -
保留泛型相关反射入口类：如使用
TypeToken模式，需保留匿名内部类及其构造逻辑，加规则- >(){}
-keep class * extends com.google.gson.reflect.TypeToken {(...); } -
避免泛型类名被重命名：若子类继承了带泛型的父类（如
class MyList extends ArrayList），需保留父类名和泛型边界，否则getGenericSuperclass()解析失败，可加-keep class **.ArrayList或更精准的包路径限定 -
禁止混淆
InnerClass和EnclosingMethod属性：匿名内部类依赖这些属性定位外层类上下文，缺失会导致TypeToken等技巧失效，应加-keepattributes InnerClasses,EnclosingMethod
常见失效场景与验证方式
混淆后泛型签名是否完好，不能只看代码能否编译，而要实测运行时反射结果：
- 打印
clazz.getGenericSuperclass()，确认返回的是ParameterizedType而非Class - 对泛型字段调用
field.getGenericType()，检查是否为ParameterizedType并能正确获取getActualTypeArguments() - 使用
new TypeToken后，传给Gson解析，验证反序列化是否保持嵌套类型
Android开发特别注意点
AGP 8.0+ 默认启用R8完整模式，但minifyEnabled true下仍可能因过度优化丢失签名。建议：
- 在
proguard-rules.pro中显式添加上述-keepattributes规则 - 禁用
assumenosideeffects对java.lang.Class.getGenericXXX系列方法的优化（它们有副作用） - 若使用Kotlin，还需保留
KotlinMetadata属性（-keepattributes KotlinMetadata），否则协程挂起函数的泛型参数也可能不可见
