反射调用参数类型不匹配会抛IllegalArgumentException，需用getParameterTypes()校验并显式转换；类加载器隔离导致ClassNotFoundException，插件类须用其自身ClassLoader加载；方法签名变更引发NoSuchMethodException，应注解驱动版本匹配；高频反射需缓存Method或改用MethodHandle优化性能。
反射调用时传参类型不匹配导致 IllegalArgumentException
Java 反射里最常踩的坑：用 invoke() 调用目标方法时，传进去的参数类型和方法签名对不上——哪怕只是 int 和 Integer、String[] 和 Object[] 这种细微差异，都会直接抛这个异常。
插件化场景下尤其危险：主程序不知道插件里方法的真实参数类型，靠配置或约定传参，一错就崩。
- 务必用
method.getParameterTypes()拿到真实参数类型数组，逐个比对并做显式转换（比如Integer.valueOf(str)、Arrays.asList(...).toArray()） - 避免直接把
Map<String, Object>解包成Object[]传给invoke()；先按顺序取出值，再按getParameterTypes()[i]做类型适配 - 如果插件接口允许泛型（如
<T> T process(T input)），反射无法获取运行时泛型信息，得靠插件自己在方法上加@ParameterType注解或约定返回TypeReference
用 Class.forName() 加载插件类时找不到类
不是类名写错了，而是类加载器隔离问题。主程序用 AppClassLoader，插件用自定义 URLClassLoader，互相看不到对方的类。
典型表现是 ClassNotFoundException，即使 .jar 文件已加入 URLClassLoader 的路径里。
- 插件类必须用加载它的那个
ClassLoader去forName()，不能用Thread.currentThread().getContextClassLoader()或默认类加载器 - 如果主程序要传递对象给插件（比如配置对象），这个对象的 class 必须由插件类加载器能访问——要么放在插件 jar 包里，要么主程序把该 class 打包进共享 lib 目录，并让插件类加载器的 parent 指向它
-
URLClassLoader构造时别漏掉parent参数，否则会断掉双亲委派，连java.lang.String都可能加载失败
接口动态适配时方法签名变更引发 NoSuchMethodException
插件系统依赖接口契约，但实际开发中，插件作者升级了接口（比如新增参数、改返回类型），而主程序没同步更新调用逻辑，反射就找不到对应方法。
这不是编译期报错，是运行时报，上线后才暴露。
- 不要硬编码方法名和参数个数；改用注解驱动：在插件接口方法上加
@PluginMethod(version = "1.2")，主程序用clazz.getMethods()+ 注解筛选，再按 version 匹配 - 对可选参数，统一用
Map<String, Object>作为唯一参数，内部由插件自己解析字段；主程序只管传 map，不关心字段增减 - 如果必须支持多版本方法共存，用
getDeclaredMethod(name, types...)替代getMethod()，避免父接口方法干扰匹配
反射性能开销大，高频调用卡顿
每次 getMethod() + invoke() 比直接调用慢 50–100 倍，插件每秒处理上千请求时，这点延迟会放大成明显瓶颈。
不是不能优化，而是容易忽略缓存时机和粒度。
- 把
Method对象缓存起来（用ConcurrentHashMap<String, Method>），key 拼成className#methodName#paramTypesHash，避免每次重新查找 - 更进一步，用
MethodHandle替代Method.invoke()：首次用MethodHandles.lookup().unreflect(method)获取，后续调用快 3–5 倍 - 别缓存
Class对象本身——它本来就是单例；但别忘了插件热更新后，旧Class实例仍存在，缓存的Method或MethodHandle必须清掉
反射不是黑魔法，它是把编译期检查换成了运行期责任。参数类型、类加载边界、方法契约、缓存生命周期——每个点都得手动兜底，漏一个，插件就掉链子。
