Java 不允许跳过父类构造器直接向祖父类传递参数，这是由语言设计强制保障的封装原则决定的；即使使用反射也无法修改已编译类的构造链行为。
java 中无法通过反射或常规语法绕过父类构造器直接调用祖父类构造器，这是由语言设计强制保障的封装原则决定的；即使使用反射也无法修改已编译类的构造链行为。
在 Java 的继承模型中，子类构造器必须且只能通过 super(...) 显式或隐式调用其直接父类的构造器，而该父类构造器再负责调用它自己的父类（即祖父类）构造器。这种单级向上委托机制是编译期强制约束，不可绕过——你无法写出 super.super(...)，也无法通过反射在运行时“重定向”构造链。
例如，假设 SDK 提供：
public class SdkClass {
public SdkClass(String config) { /* ... */ }
}
Lib 封装为：
public class LibClass extends SdkClass {
public LibClass() {
super("default-config"); // 固定传参，不可更改
}
}
而你的 MyClass extends LibClass，无论怎样重写构造器，都只能调用 super()（即 LibClass()），继而触发 SdkClass("default-config")。你无法让 MyClass 的实例最终调用 SdkClass("my-custom-config")。
Java JDK 25 来自 OpenJDK 官方归档，版本为 JDK 25，本条下载地址已指向官方 Windows x64 zip 安装包直链，适合调试旧项目或兼容旧版 Java 运行环境。
⚠️ 为什么反射也无效？
- 构造器调用发生在对象实例化之前，属于 JVM 类加载与初始化阶段的底层语义；
- Constructor
反射 API 只能调用可见的、已声明的构造器，且仍需满足继承链约束（即 LibClass 的构造器本身不暴露接受自定义 SdkClass 参数的入口）； - 试图通过 Unsafe 或字节码增强（如 Byte Buddy）篡改构造逻辑，属于高风险黑盒操作，破坏类契约、引发 VerifyError、不兼容模块化/JEP 396 封装，并被现代 JDK 明确限制。
✅ 可行替代方案：
-
组合优于继承（推荐）
放弃 extends LibClass，改为持有 LibClass 实例（或其接口），并通过包装器模式扩展行为：public class MyClass { private final SdkClass sdkInstance; // 直接构造你需要的 SdkClass public MyClass() { this.sdkInstance = new SdkClass("my-custom-config"); } } 依赖注入框架（如 Spring）
若项目已使用 Spring，可利用 @Primary、@Qualifier 或 @Bean 工厂方法控制 SdkClass 实例的创建，再注入到 LibClass 的子类中（注意：需确认 LibClass 是否支持 setter 注入或有无其他扩展点）。联系 Lib 维护者或使用 Fork
若 Lib 开源，可提交 PR 增加受保护的构造器（如 protected LibClass(String sdkArg)）；若闭源但允许定制，可协商提供扩展钩子。
? 总结：Java 的构造器链是刚性、单向、不可跳过的。所谓“跳过父类调用祖父类”，本质上违背了面向对象中“子类应完全兼容父类契约”的里氏替换原则。面对受限的第三方库，优先选择组合、代理或依赖抽象，而非强行突破语言边界——这既是稳健性的体现，也是专业工程实践的共识。
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
