MethodHandle 访问私有方法需用 MethodHandles.lookup() 获取的 Lookup 实例，且仅限当前类定义域内；必须用 invokeExact() 严格匹配签名，不可用 publicLookup() 或 asType() 越权；findSpecial 用于绕过动态分派调用父类非私有方法，非用于私有方法；MethodHandle 需缓存实例但不可跨类复用 Lookup。
MethodHandle 本身不绕过访问控制——它只是把“校验时机”从每次调用提前到查找阶段；私有方法能被访问，前提是 Lookup 对象拥有对应权限，不是靠 setAccessible(true) 那套机制。
MethodHandle 访问私有方法必须用 lookup()，不能用 publicLookup()
publicLookup() 只能看到 public 成员，连 protected 和 package-private 都不可见，更别说 private。真正能触达私有方法的，是 MethodHandles.lookup() 返回的 Lookup 实例——但它只对「当前类定义域内」的私有成员有效。
- 如果你在
ClassA里写MethodHandles.lookup().findSpecial(...)，可以拿到ClassA自己的私有方法，或其父类中被ClassA覆盖但未重写的私有方法（注意：Java 中 private 方法不可被继承，所以实际只能是本类声明的） - 想从
ClassB访问ClassA的私有方法？不行——lookup()的权限边界就是「调用点所在类」，这是 JVM 级硬约束，不是 Java 语言层可 hack 的 - 常见误操作：
MethodHandles.publicLookup().in(SomeClass.class).findPrivate(...)—— 这会直接抛NoSuchMethodException，因为 publicLookup() 根本不支持findPrivate
invokeExact 是唯一安全调用私有方法的方式
私有方法没有多态、没有重载解析、没有自动装箱/拆箱适配空间。一旦类型不匹配，invoke() 或 invokeWithArguments() 会在运行时尝试转换，但私有方法的签名在查找时已由 MethodType 锁死，强制转换极易失败，且掩盖真实类型错误。
- 用
invokeExact()：参数类型、个数、返回值类型必须与MethodType完全一致，比如目标方法是private int calc(String, long)，你就得传String和long，不能传"123"和456L（虽然字面量没问题），更不能传Integer或Long - 不要依赖
asType()去“适配”私有方法——它会生成新句柄，但底层仍受限于原始访问权限；若原始句柄无权访问，asType()不会帮你越权 - 调试时如果报
WrongMethodTypeException，优先检查MethodType.methodType(...)是否和目标方法签名一字不差，尤其注意基本类型（int≠Integer）和数组维度（String[]≠Object[]）
用 findSpecial 绕过虚方法分派，实现父类私有逻辑复用
Java 中 private 方法天然非虚，但 findSpecial 的真正价值在于：它能跳过子类重写，强制调用指定类版本的方法——哪怕那个方法在子类里被覆盖了，只要它是 non-static、non-private 的实例方法（注意：private 方法本身不能被覆盖，但 findSpecial 可用于调用父类的 non-private 方法）。
- 典型场景：子类
Son重写了think()，但你想在Son内部调用父类Father.think()的原始逻辑，又不想暴露Father.think()为 protected ——这时用lookup().findSpecial(Father.class, "think", methodType, Son.class) - 第三个参数
Son.class是关键：它告诉 JVM “以Son的类型上下文去解析方法”，但目标类锁定为Father，从而绕过 invokevirtual 的动态绑定 - 这个技巧不适用于 private 方法本身（因为 private 方法无法被子类继承或调用），但它常被误认为是“调用私有方法”的手段，需特别区分
代理重构时别漏掉 MethodHandle 的不可变性与缓存成本
每个 MethodHandle 实例是不可变的，但频繁创建（如每次请求都 new Lookup → findVirtual → bindTo）会触发大量 LambdaForm 生成和 JIT 编译压力，反而比反射还慢。
- 必须缓存
MethodHandle实例，尤其是跨线程复用的代理逻辑；推荐存在static final字段或 ConcurrentHashMap 里，避免重复查找 - 不要缓存
Lookup实例——它带类加载器和访问上下文，生命周期应与调用点类一致；反复复用一个 Lookup 没问题，但别跨类传递 - 如果代理需要处理多种参数组合（比如泛型擦除后的方法），
invokeWithArguments()看似方便，实则每调用一次都触发 Object[] 包装和类型推导，性能损失明显；宁可用多个预编译好的MethodHandle+ 分发逻辑
最易被忽略的一点：MethodHandle 的权限检查发生在 findXxx() 阶段，而不是 invoke 阶段——这意味着，如果类加载器策略变更（如模块系统隔离、SecurityManager 启用）、或目标类被 redefine，缓存的 MethodHandle 可能突然失效，且错误堆栈指向查找点而非调用点，排查难度陡增。
