MethodHandle不支持隐式转换，因类型必须严格匹配，否则抛WrongMethodTypeException；其高性能源于零运行时适配，可内联优化，而自动装箱或asType()临时转换会破坏该优势。
MethodHandle 本身不支持隐式转换，这是它和反射最根本的区别之一。所谓“隐式转换”（比如 int 自动转 Integer、String 自动转 Object）在 invokeExact 调用中完全不存在；一旦类型不匹配，立刻抛 WrongMethodTypeException。
为什么不能依赖隐式转换？
因为 MethodHandle 的高性能正来自“零运行时适配”：JVM 在调用前已确认签名完全一致，可直接生成高效机器码，甚至内联。任何自动装箱、拆箱、向上转型，都会触发 asType() 生成新句柄，破坏内联机会，性能回落到反射水平。
- int.class 和 Integer.class 是两个完全不同的类型，句柄不可互换
- String.class 和 Object.class 也不兼容——哪怕 String 是 Object 子类
- invoke() 看似能“凑合过”，但本质是每次调用都动态插入转换逻辑，开销大且不可预测
需要适配时，必须显式转换
如果确实要桥接不同类型（例如 JSON 解析后参数是 Object，但目标方法要 int），必须提前用 asType() 构造适配句柄，并缓存复用，而不是在调用时临时转换：
- 在初始化阶段完成转换：如
mh.asType(MethodType.methodType(void.class, Object.class)) - 转换后务必验证：用
handle.type()打印签名，逐个比对参数和返回类型 - 避免在循环或高频路径中反复 asType——这会创建大量临时句柄，GC 压力大，且 JIT 无法优化
基本类型字段访问的典型写法
访问 private int id 字段，必须明确使用原始类型声明句柄：
- ✅ 正确：
lookup.findGetter(Target.class, "id", int.class) - ❌ 错误：
lookup.findGetter(Target.class, "id", Integer.class)—— 触发装箱，性能受损 - ❌ 更错：
lookup.findGetter(Object.class, "id", int.class)—— 泛型擦除导致 JVM 无法优化
跨模块或 private 成员的权限处理
隐式转换问题常被误认为是权限问题。实际上，Lookup 权限不足会导致 findVirtual 返回 null 或抛 IllegalAccessException，而非类型异常。若调用时报 WrongMethodTypeException，优先检查类型是否严格一致，再排查模块导出或 privateLookupIn 是否到位。
