本文详解 java 反射调用泛型 varargs 方法的核心难点：因 `method.invoke()` 本身是 varargs 方法，直接传入对象数组会被二次展开，导致类型不匹配；正确解法是显式将参数数组强制转型为 `object` 类型，或改用 `methodhandle` 避免歧义。
在 Java 反射中调用泛型类的可变参数方法（如 <T> void add(T... args)）时，开发者常陷入一个经典陷阱：方法签名查找正确，但 invoke() 调用始终失败。根本原因并非泛型擦除（你已正确使用 Object[].class 获取擦除后的方法），而是 Method.invoke(Object obj, Object... args) 与目标方法 add(T...) 同为 varargs，引发参数传递的语义冲突。
? 问题本质：双重 varargs 的歧义
invoke() 接收 Object...，当你传入 new Object[]{si} 时，JVM 会将其自动解包为单个参数 si（即等价于 invoke(obj, si)），而非作为 add 方法期望的「一个 Object[] 参数」。这导致运行时实际传入的是 SomeInterface 实例，而 add 方法签名要求 Object[]，类型不匹配，抛出 IllegalArgumentException。
✅ 正确做法：切断 invoke 的自动解包行为，通过强制类型转换明确告知 JVM：“这是一个整体参数，不要展开”。
Method method = clazz.getMethod("add", Object[].class);
// ✅ 关键：将参数数组显式转为 Object 类型
method.invoke(obj, (Object) new Object[]{si});该转换使 new Object[]{si} 不再被 invoke 视为 varargs 元素，而是作为单一 Object 参数传递，完美匹配 add(Object[]) 的擦除签名。
立即学习“Java免费学习笔记（深入）”；
? 更优雅的替代方案：MethodHandle
Java 7 引入的 MethodHandle 完全规避了此问题——其 invoke() 是签名多态（signature-polymorphic）方法，不进行任何隐式转换或解包，且能智能识别目标方法是否为 varargs 并自动完成数组封装：
MethodHandle mh = MethodHandles.lookup()
.findVirtual(obj.getClass(), "add",
MethodType.methodType(void.class, Object[].class));
mh.invoke(obj, si); // ✅ 自动将 si 封装为 Object[]{si}，无需手动构造数组? 提示：MethodHandle 还支持更灵活的参数适配（如自动装箱、类型转换），且性能通常优于反射（尤其在多次调用时）。
⚠️ 注意事项与最佳实践
- 永远避免裸传数组：method.invoke(obj, arr)（其中 arr 是引用类型数组）必然触发解包，应统一写作 (Object) arr。
- 泛型无关性：此问题与泛型无关，任何 varargs 方法（如 String.format(String, Object...)）在反射中都需同样处理。
- 空参调用：调用无参数的 varargs 方法时，传 null 或 (Object) new Object[0] 均可，但推荐后者以明确语义。
- 异常处理：务必捕获 InvocationTargetException（包装目标方法异常）和 IllegalAccessException，而非仅 Exception。
掌握这一细节，即可在动态代理、通用序列化框架或 DSL 解析器等场景中，稳健地操作泛型 varargs 方法，让反射真正成为类型安全的利器。
