bindto 用于预绑定第一个参数（如 receiver），而非委托；正确用法是 lookup → findxxx → bindto（仅实例方法且 receiver 固定）→ invokeexact，缺一不可。
bindTo 不是用来“委托”的，它是用来“预绑定第一个参数”的；想替代反射调用，必须配合 findVirtual / findStatic 等查找 + bindTo（仅当需要固定 receiver）+ invokeExact 三步走，缺一不可。
bindTo 的真实作用：不是委托，是参数固化
很多人误以为 bindTo 是把方法“绑定到某个对象上”以实现类似 lambda 的委托效果。实际上它只是在调用链最前端插入一个固定值——比如 mh.bindTo(obj) 生成的新句柄，其签名会比原句柄少一个参数（通常是 receiver），后续调用时无需再传 obj。
常见错误现象：WrongMethodTypeException，往往是因为原 MethodHandle 是静态方法句柄（无 receiver 参数），却对它调用 bindTo；或原句柄是实例方法但未用 findVirtual 构造，导致签名不匹配。
-
findStatic返回的句柄第一个参数不是 receiver，不能bindTo（否则类型错） -
findVirtual或findSpecial返回的句柄第一个参数是 receiver，才适合bindTo(this) - 绑定后新句柄的
type()会显示参数列表已移除首项，可用System.out.println(mh.type())验证
正确组合：lookup → findXxx → bindTo（可选）→ invokeExact
要真正替代 method.invoke(obj, args...)，必须按 JVM 类型系统要求严格构造句柄链。重点不是“能不能用 bindTo”，而是“该不该用、在哪一步用”。
- 调用实例方法且 receiver 固定（如单例工具类方法）：用
findVirtual获取句柄，再bindTo(instance)，后续只传剩余参数 - 调用实例方法但 receiver 不固定（如遍历 list 调用每个元素的
toString()）：跳过bindTo，直接用invokeExact(obj, ...)，避免每次重新绑定 - 调用静态方法：直接
findStatic+invokeExact(args...)，bindTo完全无意义 - 性能关键路径务必用
invokeExact，而非invokeWithArguments（后者会做运行时类型推导，开销接近反射）
容易被忽略的兼容性陷阱
bindTo 在 Android 上需 API 26+（Android 8.0），且 Mono.Android.dll 中的封装仅在 .NET for Android API 35 中稳定支持。JVM 端虽从 JDK 7 就存在，但不同厂商的 JIT 对 bound handle 的内联优化程度差异很大。
- OpenJDK 17+ 中，
bindTo后的句柄大概率被 JIT 内联为 invokevirtual，性能逼近直接调用 - 某些旧版 Android ART 运行时可能无法有效优化 bound handle，实测反而比未绑定 + 显式传参慢 10%～15%
- 如果目标方法含泛型桥接方法（bridge method），
findVirtual可能返回错误句柄，建议用findSpecial+ 显式指定 owner class 规避 -
bindTo(null)在 receiver 为基本类型包装类时可能触发 NPE，应提前判空或改用invokeWithArguments（牺牲性能换安全）
真正难的不是写对 bindTo，而是判断“这个 receiver 到底该不该固化”——它和业务生命周期强耦合。比如缓存一个绑定了 DAO 实例的 save 句柄，一旦 DAO 被销毁，这个句柄就成悬垂引用，而反射至少还能抛 IllegalAccessException 给你个提示。
