父子类初始化顺序由JVM类加载和对象创建两阶段分层控制：静态部分父类优先、仅执行一次；实例部分每次new时自顶向下进入、自底向上返回，父类构造器先于子类完成。
掌握父子类初始化顺序，关键不是死记步骤，而是理解 JVM 在类加载和对象创建两个阶段的分层控制逻辑。它不是“一行行代码从上往下跑”，而是由类结构和运行时机共同驱动的流水线。
静态部分：类加载时一次性完成，父类优先
静态变量赋值和静态代码块被编译器合并进 <clinit>()</clinit> 方法，按源码声明顺序执行。JVM 加载子类前，必须先完成父类的整个静态初始化——哪怕你只写 new Child()，也会触发 Parent.class 的加载、准备、初始化三步。
- 父类静态变量默认值 → 父类静态变量显式赋值 + 静态块（从上到下）
- 子类静态变量默认值 → 子类静态变量显式赋值 + 静态块（从上到下）
- 静态初始化只发生一次，后续再 new 或调用静态方法都不会重复执行
实例部分：每次 new 时按继承链逐层展开
构造一个子类对象，本质是“自顶向下进入、自底向上返回”的递归过程。父类构造器必须先完成，子类才能继续；而父类构造器内部，又会先处理完自己的实例变量和构造块，才执行构造函数体。
- 父类实例变量默认值 → 父类实例变量显式赋值 + 构造块（从上到下）→ 父类构造函数体
- 子类实例变量默认值 → 子类实例变量显式赋值 + 构造块（从上到下）→ 子类构造函数体
- 注意：
super()是隐式或显式的第一条语句，它把控制权交给父类构造流程；父类构造结束，才回到子类继续执行
实战调试技巧：用日志锚定每个环节
不要靠猜，用带标识的 System.out.println 直接验证执行流。重点打在四类位置：
sc-java-to-ts-interface
下载
将后端 Java 接口文档转换为前端 TypeScript 类型定义（interface / type）。输入：飞书文档、Spring Boot 接口文档、Swagger/OpenAPI、手写 API 文档等。输出：包含请求参数与响应结果的 .md 文件，含完整 JSDoc 注释。触发关键词：Java 转 TS、接口转换、生成前端类型、接口文档转 TypeScript、DTO/VO/BO 转 interface、后端文档转前端类型、生成接口类型、类型定义生成。
立即学习“Java免费学习笔记（深入）”；
- 每个
static{}开头加"[S] Parent"类标记 - 每个
{}（构造块）开头加"[I] Parent" - 每个构造函数第一行加
"[C] Parent()" - 每个成员变量初始化（如
String s = init();）中，在init()方法里也加日志
观察输出是否严格符合 “S-P → S-C → I-P → C-P → I-C → C-C” 模式。一旦出现错位，说明有静态依赖循环、this() 调用干扰或字段初始化抛异常中断流程。
常见陷阱与规避方式
初始化顺序错误往往不报编译错误，但会导致字段为 null、状态不一致或死锁。
- 在静态块里访问子类未初始化的静态字段：改成延迟初始化（如 Holder 模式），或确保依赖字段声明在前
- 构造块中调用可被重写的方法：子类字段尚未赋值，方法可能读到默认值（如 0、null），应避免或改用 final 方法
- 父类构造器中调用子类重写方法：此时子类实例变量还未初始化，极易 NPE；设计上应让父类构造器只做基础设置，复杂逻辑后移
- 静态变量直接 new 子类实例：会提前触发子类静态初始化，可能造成类加载顺序混乱，建议用静态方法封装初始化逻辑
