super() 是委托父类初始化当前对象，而非单纯调用父类构造器；它强制在子类对象内存分配后立即完成父类部分初始化，是继承链中不可省略的显式跳转点。
super() 不是“调用父类构造器”，而是“委托父类初始化当前对象”
很多人以为 super() 是像普通方法一样去“执行父类的构造器代码”，其实它更接近一个强制性的初始化协议：子类对象在堆上分配内存后，必须立刻让父类部分完成初始化，否则该对象处于非法状态。JVM 在实例化时会把整个继承链的构造器串成一条执行链，super() 就是这条链上的显式跳转点。
常见错误现象：Implicit super constructor Xxx() is undefined —— 这不是说父类没写构造器，而是子类没显式写 super(...)，而父类又没有无参构造器，编译器无法自动插入默认调用。
- 如果父类只有带参构造器，子类构造器第一行必须写
super(…)，不能省略 -
super()必须是子类构造器的第一条语句（哪怕你加了注释或空行也不行） - 不能在普通方法里写
super()，它只在构造器中合法；也不能在静态上下文里出现
构造器链执行时，字段初始化顺序比你以为的更严格
Java 对象创建分三步：内存分配 → 字段默认初始化（0 / null / false）→ 构造器执行。但构造器内部的字段赋值，和父类构造器中的字段赋值，顺序由继承链决定，不受源码书写位置影响。
使用场景：当父类构造器里调用了可被重写的方法（比如 init()），而子类重写了它，这时子类字段可能还没初始化，却已被父类构造器间接访问——这是典型的 NullPointerException 或未定义行为根源。
立即学习“Java免费学习笔记（深入）”；
- 父类字段初始化语句（如
int x = 10;）在父类构造器体执行前完成 - 子类字段初始化语句在子类构造器体执行前完成，但一定在父类构造器执行完之后
- 所以
super()调用后、子类构造器代码开始前，父类部分已就绪，但子类字段仍是默认值
class Parent {
String name = "parent"; // ← 这行在 super() 返回后才生效
Parent() {
printName(); // 实际调用子类重写的 printName()
}
void printName() { System.out.println(name); }
}
class Child extends Parent {
String name = "child"; // ← 这行此时还是 null！
Child() { super(); } // ← 父类构造器已执行，但子类 name 还没赋值
}
不写 super() 不等于没调用父类构造器
只要子类构造器没显式写 super(...) 或 this(...)，编译器会在第一行自动补上 super()。这个隐式调用只适用于父类存在无参构造器的情况。
性能/兼容性影响：隐式 super() 和显式写出来，在字节码层面完全一致，没有运行时开销差异。但它会让继承关系更脆弱——一旦父类删掉无参构造器，所有没显式调用的子类都会编译失败。
- IDE 自动生成构造器时，默认插的是
super()，容易掩盖父类设计变化 - 使用 Lombok 的
@RequiredArgsConstructor时，若父类无无参构造器，需手动配@SuperBuilder或显式写构造器 - Android 中
View子类常需处理多个构造签名（Context+AttributeSet），漏掉某个super(...)会导致Resources not found类错误
super() 和 this() 不能共存，但可以形成完整初始化路径
super() 和 this() 都必须是构造器首句，因此二者互斥。但你可以用 this() 去调同个类的另一个构造器，再由那个构造器去调 super()，从而实现参数归一化。
容易踩的坑：在 this() 链中绕过 super()，比如试图用两个 this() 跳转最后却不触发父类构造器——编译器会直接报错：call to super must be first statement in constructor。
- 所有构造器最终都必须抵达一个调用
super(...)的出口，否则编译失败 - 如果父类是
final且只提供私有构造器（如某些工具类），子类根本无法继承，super()无从谈起 - 枚举类隐式继承
java.lang.Enum，其构造器固定为Enum(String, int)，你写的枚举构造器里super()是自动注入的，不可见也不可改
super() 看似简单，真正复杂的是它背后绑定的内存布局协议和字段生命周期约束。多数 bug 不出在语法上，而出现在误判“此时哪个字段已经就绪”。 
