反射调用泛型方法异常主因是误调桥接方法；需用javap识别acc_bridge方法，调用前过滤isbridge()为true的方法，并按擦除后实际类型匹配。
反射调用泛型方法时抛出异常，往往不是泛型本身的问题，而是没识别出编译器悄悄生成的桥接方法（bridge method），导致调用路径错位。关键不在“怎么调”，而在“调的是哪个方法”。
看清桥接方法的真实存在
桥接方法是编译器为兼容泛型擦除而自动生成的合成方法，不写在源码里，但真实存在于字节码中。它被标记为 ACC_BRIDGE + ACC_SYNTHETIC，签名已擦除（比如参数从 T 变成 Object），内部只做类型转发。
排查第一步：用 javap -v ClassName.class 查看方法表，找带 bridge 和 synthetic 标志的方法。例如：
- 接口定义：
void set(T item) - 实现类写了：
public void set(String s) - 字节码中实际会有两个
set：一个参数是String（你写的），一个参数是Object（桥接方法）
定位异常根源：常见三类误调场景
反射未过滤桥接方法，极易触发以下异常，每种背后都有明确的调用错位逻辑：
-
ClassCastException：反射匹配到桥接方法（参数为
Object），却传入String；方法体里再强转为具体类型失败 -
NoSuchMethodException：Android 上 R8 默认移除桥接方法，
getDeclaredMethod("xxx", Object.class)直接找不到，fallback 逻辑被反复触发 - AbstractMethodError：向上转型后通过接口引用调用，JVM 实际分派到桥接方法，但该方法被意外过滤或字节码篡改，导致找不到重写入口
反射调用前必须做的三步过滤
不要依赖方法名+参数类型直接查，要主动识别并排除干扰项：
- 用
clazz.getMethods()或getDeclaredMethods()获取全部同名方法 - 逐个检查
method.isBridge() == false，这是最轻量、最可靠的判断依据 - 再按业务语义筛选：参数数量匹配 + 参数类型为擦除后的实际类型（如
String.class，不是Object.class） + 返回类型符合预期（如List.class而非Object.class）
高频调用场景的加固建议
生产环境尤其要注意反射结果缓存与复用，避免每次调用都重复遍历和判断：
- 缓存层只存
!m.isBridge()的 Method 实例，并绑定其泛型声明（m.getGenericReturnType()）供后续类型推断使用 - 对关键泛型方法（如 DAO 层的
save(T)、findById(ID)），封装统一的查找工具方法，内置桥接过滤逻辑 - 避免用
getMethod("xxx", Object.class)这类宽泛签名匹配——它天然倾向命中桥接方法
