Java子类构造时先执行父类构造方法，因对象初始化需父类结构就绪；private成员不参与继承可见性但存在于子类内存中；Java单继承避免菱形问题，用接口实现多扩展。
new 子类时为什么先执行父类构造方法？
因为 Java 的对象初始化顺序是强制的：子类实例必须建立在父类结构已就绪的基础上。JVM 在执行 new Dog() 时，会先确保 Dog 所依赖的父类（如 Animal）字段、方法表、虚函数表等运行时结构已加载并初始化完毕。
- 若父类只有带参构造器（如
Animal(String name)），子类构造器中**必须显式调用super(...)**，否则编译失败 - 即使没写
super()，编译器也会自动插入无参super()—— 但前提是父类存在无参构造器 - 父类构造器执行完后，才轮到子类自己的字段初始化和构造器剩余逻辑
private 成员真的“不可继承”吗？
准确地说：private 成员**不参与继承链的可见性传递**，子类中既不能直接访问，也不能重写，但它仍存在于子类对象内存布局中（通过父类构造器初始化）。
- 子类无法写
this.name（如果name是父类private字段） - 但可通过父类提供的
public/protected方法间接操作，比如getName()或setName(...) - 反射可以绕过访问限制，但这属于运行时 hack，不属于继承机制本身
为什么 Java 只支持单继承？
为避免“菱形继承问题”（Diamond Problem）导致的方法解析歧义和状态冲突。例如，若 class C extends A, B，而 A 和 B 都定义了同名同签名的 display()，JVM 无法安全决定调用哪个。
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
- Java 用接口（
interface）替代多继承的扩展能力：一个类可implements多个接口 - 接口默认方法（
default）虽支持多实现，但若多个接口提供同名default方法，子类**必须显式重写该方法**，消除歧义 - 多层继承（如
A → B → C）完全合法，且是构建清晰领域模型的常用手段
子类重写方法时 super 调用不是可选的，而是语义关键
@Override 方法中是否调用 super.xxx()，决定了你是在“增强”还是“替换”父类逻辑。这不是语法要求，而是设计意图的体现。
立即学习“Java免费学习笔记（深入）”；
- 不调用
super：完全覆盖行为（如Dog.eat()输出“吃骨头”，不提“进食”通用动作） - 调用
super：在父类逻辑基础上追加（如先打印“动物进食”，再打印“小狗汪汪叫”） - 错误地在重写中漏掉
super可能导致资源未初始化、日志缺失、状态不一致等隐性 bug
class Animal {
void eat() {
System.out.println("动物进食");
}
}
class Dog extends Animal {
@Override
void eat() {
super.eat(); // 关键：保留父类基础行为
System.out.println("小狗吃骨头");
}
}
子类对象的内存里确实包含父类字段副本，但能否访问、如何初始化、怎样协同行为——这些都不是靠“复制代码”实现的，而是 JVM 类加载、对象创建、方法分派三阶段协作的结果。真正容易被忽略的，是构造器链与字段初始化顺序的严格耦合；一旦打破，看似运行正常的代码，可能在多线程或序列化场景下突然暴露竞态或空指针。 
