WrongMethodTypeException 是 MethodHandle 类型检查失败的直接信号，源于 invokeExact/invoke 时参数、返回或泛型擦除后类型与 MethodType 不匹配，需严格比对 type() 并慎用 asType。
WrongMethodTypeException 是 MethodHandle 类型检查失败的直接信号
这个异常不是运行时偶然出错，而是 JVM 在 invokeExact 或 invoke 时严格比对签名后主动抛出的——说明你传入的参数类型、返回类型或泛型擦除后实际类型，和 MethodHandle 的类型描述（MethodType）不一致。它不关心逻辑对不对，只认字节码层面的类型签名。
常见错误现象：
• 调用 invokeExact 时传了 int 却期望 Integer
• 方法返回 String，但你用 Object.class 去接收，而 MethodHandle 的类型声明是 String.class
• 使用 findVirtual 获取非 public 方法后，未用 asType 适配桥接方法的签名
- 永远优先用
invokeExact测试——它不做自动装箱/拆箱、类型转换，能最早暴露类型错配 - 如果必须兼容性调用，改用
invoke，但它仍会拒绝跨类型层级的转换（比如String→Number） - 检查
MethodHandle.type()输出，和你实际传参/接收的类型逐字段比对，尤其注意原始类型和包装类的区别
asType 不是万能转换器，它只做合法的类型适配
asType 看起来像“强转”，其实只是按 JVM 规则生成一个新的 MethodHandle，其类型描述被重写为指定的 MethodType。但它不会插入转换逻辑，也不支持非法映射。
使用场景：
• 把返回 Object 的句柄适配成返回具体子类（如 asType(MethodType.methodType(String.class))）
• 给原始类型参数补上装箱（int → Integer），前提是目标方法签名明确接受包装类
• 消除泛型擦除带来的类型差异（比如 List<string></string> 和原始 List）
立即学习“Java免费学习笔记（深入）”；
当用户要求为 Java 代码添加注释、修改注释、审查注释、整理注释格式，或要求按照代码注释规范处理 Java 文件时，使用本技能。本技能用于统一生成和维护 Java 类注释模板、按 Git 对比 release 判断版本号、补充每行代码上方中文块注释、调整注释空行规则，并保持 Java 文件 UTF-8 无 BOM 编码。典型触发场景包括：补充类注释、更新 @version、检查 @author 来源、整理行尾注释、把注释放到代码上一行、检查注释是否符合规范、构建前检查 Java 注释风格。
-
asType失败也会抛WrongMethodTypeException，不是静默失败 - 不能用
asType把void方法转成有返回值，也不能把有返回值方法转成void - 对数组类型要小心：
String[]和Object[]虽然运行时可协变，但asType默认不认为它们兼容，需显式构造正确MethodType
MethodHandle 的类型在创建时就固定，无法动态修改
从 Lookup.find*()、MethodHandles.constant() 或 MethodHandles.identity() 得到的 MethodHandle，其 type() 是不可变的。后续所有 asType、bindTo、filterArguments 都是返回新句柄，原句柄不变。
容易踩的坑：
• 修改了参数顺序或个数后没重新 asType，直接调用导致异常
• 多次链式调用（如 mh.asType(...).bindTo(...).asType(...)）后忘了最终类型是否匹配实际调用点
• 把 MethodHandle 当作普通对象缓存，却忽略了它的类型是“快照式”的，和原始方法签名强绑定
- 调试时打印
mh.type().toString()，比猜更可靠 - 避免深层链式调用；建议每步都赋值给带含义的变量，比如
mhAfterBind、mhForStringReturn - 如果目标方法是泛型且涉及类型变量，确认
Lookup实例是否通过in指定了正确的类，否则findVirtual可能返回桥接方法，签名和预期不符
与反射 API 混用时，类型语义容易错位
用 Method.invoke() 获得的结果，再喂给 MethodHandle，或者反过来，常因隐式转换规则不同引发 WrongMethodTypeException。反射允许更多宽松调用（比如自动装箱），而 MethodHandle 更接近字节码契约。
典型场景：
• 用反射拿到 Method 后调用 MethodHandles.lookup().unreflect(method)，但该方法有 varargs 参数，unreflect 生成的 MethodHandle 类型含 Object...，而你传的是 String[]，不等价
• 把 MethodHandle 的结果传给需要 Class> 的反射方法，却忘了 MethodHandle 返回的是实例而非 Class 对象
- varargs 方法经
unreflect后，type()中最后一个参数是Object[]，不是可变参数语法糖；调用时必须传数组，不能展开 - 不要试图用
MethodHandle替代反射做“通用调用器”，它的优势在性能和类型安全，不在灵活性 - 如果必须混用，中间加一层显式类型断言或转换，比如用
Objects.requireNonNull((String) mh.invokeExact(...))强制触发类型检查
最麻烦的不是报错本身，而是类型错配可能藏在嵌套调用深处，比如 filterArguments 插入的过滤器返回类型和下游期望不一致——这种时候，单看异常堆栈根本看不出哪一环的 type() 对不上。
