必须调用setAccessible(true)才能反射调用方法，否则抛IllegalAccessException；需处理InvocationTargetException包装、参数类型匹配、模块化访问限制及Method缓存优化。
Method.invoke() 调用前必须确保方法可访问
反射调用失败最常见的原因是 IllegalAccessException，哪怕方法是 public 的——因为 Method 对象默认不绕过 Java 访问控制。必须显式调用 setAccessible(true) 才能触发 private/protected 方法，甚至某些模块化环境（Java 9+）下对 public 方法也需此步。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 始终在
invoke()前加method.setAccessible(true)，别依赖“它看起来是 public 就不用” - 如果目标类在 module-info.java 中未导出包，
setAccessible(true)可能抛InaccessibleObjectException，需在 JVM 启动时加--add-opens参数（如--add-opens java.base/java.lang=ALL-UNNAMED） - 对静态方法，
invoke()的第一个参数传null；实例方法则必须传对应对象实例，不能传null
传参类型不匹配会导致 IllegalArgumentException
Method.invoke() 是泛型擦除后的原始方法，运行时不校验参数类型是否与声明一致，但会做基本类型自动装箱/拆箱和引用类型向上转型。一旦传入无法隐式转换的值（比如把 String 传给 int 参数），就会在运行时报 IllegalArgumentException: argument type mismatch。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 用
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() 里。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 必须用
try-catch (InvocationTargetException e)，然后调e.getCause()获取真实异常再处理或 rethrow - 如果目标方法声明抛受检异常（checked exception），反射调用时不会强制你捕获它——但
getCause()返回的仍是那个受检异常类型，可以instanceof判断后强转处理 - 不要只 catch
Exception就完事，否则会漏掉InvocationTargetException本身（比如底层反射机制出错），也掩盖了原始错误上下文
性能与安全：频繁反射调用要缓存 Method 实例
每次通过 Class.getMethod() 或 getDeclaredMethod() 查找 Method 对象开销不小，尤其在循环或高频路径中。而且反复调用 setAccessible(true) 也有成本。
实操建议：
立即学习“Java免费学习笔记（深入）”；
- 将查找到的
Method对象缓存起来（如用static final、ConcurrentHashMap或 Guava 的Cache），避免重复查找 - 缓存前务必已调用过
setAccessible(true)，否则每次 invoke 都得重复设 - 注意线程安全：
Method对象本身是线程安全的，但如果你在缓存逻辑里没同步好初始化过程，可能多个线程重复创建同一Method
真正麻烦的是跨模块调用时的 --add-opens 管理，以及异常链的逐层 unpack——这两处不细看堆栈很容易卡住半天。
