如何在 Java 中通过 Method.invoke() 动态调用一个没有在代码里硬编码的方法

Ja va反射中的Method.invoke()调用，往往是看起来简单，实际踩坑的地方却不少。先说几个核心判断：必须在调用前确保方法可访问，否则会直接报IllegalAccessException；传参类型不匹配会引发IllegalArgumentException；而最容易被忽略的，是实际抛出的异常会被包装成InvocationTargetException，根源藏在getCause()里。此外，频繁反射调用时，Method实例的缓存也是一个绕不开的性能点——对应这几个坑，下面一一拆解。

Method.invoke() 调用前必须确保方法可访问

反射调用失败最常见的原因是 IllegalAccessException，哪怕方法是 public 的——因为 Method 对象默认不绕过 Ja va 访问控制。必须显式调用 setAccessible(true) 才能触发 private/protected 方法，甚至某些模块化环境（Ja va 9+）下对 public 方法也需此步。

• 始终在 invoke() 前加 method.setAccessible(true)，别依赖“它看起来是 public 就不用”
• 如果目标类在 module-info.ja va 中未导出包，setAccessible(true) 可能抛 InaccessibleObjectException，需在 JVM 启动时加 --add-opens 参数（如 --add-opens ja va.base/ja va.lang=ALL-UNNAMED）
• 对静态方法，invoke() 的第一个参数传 null；实例方法则必须传对应对象实例，不能传 null

传参类型不匹配会导致 IllegalArgumentException

Method.invoke() 是泛型擦除后的原始方法，运行时不校验参数类型是否与声明一致，但会做基本类型自动装箱/拆箱和引用类型向上转型。一旦传入无法隐式转换的值（比如把 String 传给 int 参数），就会在运行时报 IllegalArgumentException: argument type mismatch。

• 用 method.getParameterTypes() 拿到形参类型数组，手动检查并转换实参。例如：若期望 int.class，就用 Integer.parseInt(str) 或 Number.intValue()
• 避免直接传 new Object[]{1, "hello"} 这种裸数组——如果方法签名是 void f(int, String)，没问题；但如果是 void f(Integer, String)，而你传了 int 字面量，会因自动装箱生效；可读性差且易错
• 注意可变参数（String... args）：传 new Object[]{"a","b"} 会被当做一个 Object[] 参数，而非展开为两个 String；正确做法是传 (Object) new String[]{"a","b"} 或单独构造数组

异常包装：实际抛出的异常被包裹在 InvocationTargetException 中

这是最容易忽略的点：Method.invoke() 不会直接抛出目标方法里 throw 的异常（比如 NullPointerException 或自定义 MyBizException），而是统一包装成 InvocationTargetException，原异常藏在 getCause() 里。

• 必须用 try-catch (InvocationTargetException e)，然后调 e.getCause() 获取真实异常再处理或 rethrow
• 如果目标方法声明抛受检异常（checked exception），反射调用时不会强制你捕获它——但 getCause() 返回的仍是那个受检异常类型，可以 instanceof 判断后强转处理
• 不要只 catch Exception 就完事，否则会漏掉 InvocationTargetException 本身（比如底层反射机制出错），也掩盖了原始错误上下文

性能与安全：频繁反射调用要缓存 Method 实例

每次通过 Class.getMethod() 或 getDeclaredMethod() 查找 Method 对象开销不小，尤其在循环或高频路径中。而且反复调用 setAccessible(true) 也有成本。

• 将查找到的 Method 对象缓存起来（如用 static final、ConcurrentHashMap 或 Gua va 的 Cache），避免重复查找
• 缓存前务必已调用过 setAccessible(true)，否则每次 invoke 都得重复设
• 注意线程安全：Method 对象本身是线程安全的，但如果你在缓存逻辑里没同步好初始化过程，可能多个线程重复创建同一 Method

真正麻烦的是跨模块调用时的 --add-opens 管理，以及异常链的逐层 unpack——这两处不细看堆栈很容易卡住半天。