Method.invoke()无法绕过子类重写，因其本质是虚拟方法调用，JVM严格依据对象实际类型动态分派，反射仅获取方法签名而不绑定实现，setAccessible(true)仅影响访问控制，不改变多态行为。
Java反射中通过invoke调用方法时，**无法绕过子类重写**——这是JVM多态机制的底层设计决定的，不是反射能干预的行为。所谓“绕过”，实际是指在运行时跳过动态绑定、强制调用父类版本的方法。这在标准Java中**没有合法、安全、可移植的方式**实现。
为什么invoke无法绕过重写？
反射调用Method.invoke()本质上仍是虚拟方法调用（virtual invocation），JVM会根据**实际对象类型**（而非声明类型）查找并执行最终重写的方法。即使你用getDeclaredMethod("xxx", ...)从父类Class中获取Method对象，只要目标对象是子类实例，且该方法被重写，JVM仍会执行子类版本。
常见误解与错误尝试
- 误以为用父类Class获取Method就能调用父类逻辑：错。Method对象只描述签名，不绑定具体实现；调用时仍按对象实际类型分派。
-
试图用
setAccessible(true)改变行为：该方法仅用于绕过访问控制（private/protected），不影响方法分派逻辑。 -
混淆
super.xxx()语法：那是编译期确定的静态分派，反射在运行时无法模拟super语义。
可行的替代思路
如果业务确实需要“跳过重写”执行父类逻辑，需重构设计，而非依赖反射hack：
- 将父类逻辑提取为final或static方法：避免被重写，反射可安全调用。
-
提供显式委托接口：例如父类定义
protected final void doWork() { ... }，子类重写work()时内部调用doWork()，反射调用doWork即可。 -
使用方法句柄（MethodHandle）配合
findSpecial：仅适用于已知具体类且需绕过虚调用的极少数场景（如单元测试框架），但要求调用者有足够权限，且不适用于普通业务代码（JDK9+受限更严）。
总结
Java的多态是语言核心契约，反射不会、也不应破坏它。所谓“绕过重写”本质是设计矛盾——若需父类行为，就该由父类暴露稳定入口；若需子类定制，则应接受其重写结果。强行规避只会导致行为不可预测、难以维护。
立即学习“Java免费学习笔记（深入）”；
