java父子类初始化顺序严格遵循静态→实例、父→子规则：静态部分首次使用时执行父静态变量→父静态块→子静态变量→子静态块；实例部分每次new时执行父实例变量→父实例块→父构造→子实例变量→子实例块→子构造。
Java 中父子类代码块执行顺序直接影响复杂对象的初始化完整性与状态一致性。它不是语法糖，而是 JVM 类加载和对象实例化机制的刚性体现——顺序错一点，就可能让字段为 null、数值为 0、资源未就绪，甚至触发空指针或逻辑崩溃。
静态部分决定“类是否准备好”，且只跑一次
父类静态变量赋值 → 父类静态代码块 → 子类静态变量赋值 → 子类静态代码块，这个链条在类首次被主动使用（如 new、调用静态方法、访问静态字段）时一次性完成。之后无论创建多少对象，这部分都不再执行。
- 若子类静态块依赖父类静态字段，而父类静态字段又依赖某个尚未初始化的配置类，就可能因加载顺序不当导致 NPE 或默认值误用
- final static 基本类型常量（如 public static final int TIMEOUT = 5000;）不触发类初始化；但若写成 public static final String CONF = loadConfig();，则会完整走一遍父→子静态链
- main 方法写在子类里，会导致 JVM 启动时提前加载并初始化父类——这不是 bug，是继承层级强制保障的结果
实例部分决定“每个对象是否安全可用”，每次 new 都重走一遍
每次 new 子类对象时，JVM 按固定流水线推进：父类实例变量初始化 → 父类实例代码块 → 父类构造方法 → 子类实例变量初始化 → 子类实例代码块 → 子类构造方法。
- 字段显式初始化（如 String name = getName();）会被编译器自动“塞进”对应类的实例代码块中，位置就在构造方法体之前、但严格晚于父类全部初始化完成
- 如果父类构造方法中调用了被子类重写的方法，此时子类的实例代码块还没执行，所有子类字段仍是默认值（null / 0 / false），极易引发异常
- super() 必须在子类构造方法第一行，本质不是语法限制，而是守住这条流水线起点：确保父类状态已就绪，子类才开始初始化
多层继承下顺序不变，但风险放大
三层继承 A → B → C 时，执行顺序仍是：A 静态 → B 静态 → C 静态 → A 实例块 → A 构造 → B 实例块 → B 构造 → C 实例块 → C 构造。看似线性，但每层都可能埋下隐患：
- 某层实例代码块中调用上级方法，而该方法又依赖下级未初始化的字段——这种跨层耦合在顺序固化前提下极难察觉
- 多个实例代码块混合字段初始化时，若源码顺序写反（比如先调 init() 再赋值 config），日志会显示 init() 读到的是 null 而非预期值
- 局部代码块（方法内 {}）完全不参与初始化流程，仅限作用域内执行，切勿误以为它能替代实例代码块做初始化
调试和验证的关键动作
别靠记忆猜顺序，用带标识的日志锚定每个环节：
- 静态块开头打 [S] Parent，实例块打 [I] Parent，构造方法第一行打 [C] Parent()
- 观察输出是否稳定呈现 S-P → S-C → I-P → C-P → I-C → C-C 模式
- 一旦乱序，优先排查：是否存在静态依赖循环、this() 调用干扰、或某个 init() 抛出未捕获异常中断了流程
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
