多个静态代码块按源码从上到下顺序合并进<clinit>方法，编译器不重排、只线性拼接；父类与子类的<clinit>执行顺序由JVM类加载规范决定，父类先于子类执行。
多个静态代码块的排列位置，直接决定它们在字节码中被合并进 <clinit> 方法的顺序——编译器不做重排，只做线性拼接。理解这点，就能通过源码结构反推字节码行为，是调试类初始化问题、排查静态资源加载异常的关键视角。
静态块按源码书写顺序严格合并
Java 编译器（javac）在生成字节码时，会扫描整个类体，把所有 static{...} 块按从上到下的文本位置依次提取，拼成一个单一的 <clinit> 方法。中间不会插入字段赋值以外的逻辑，也不会跨块优化或交换顺序。
- 哪怕两个静态块之间隔着 10 行字段声明、注释或空行，顺序也不变
- 静态字段显式初始化（如
static int x = getValue();）也被视为“隐式静态块”，同样按出现位置插入到<clinit>中对应位置 - 用
javap -c ClassName查看字节码，能清晰看到0: sipush、3: putstatic等指令严格按源码顺序排列
实战验证：用 javap 观察合并结果
写一个含多个静态块的测试类：
class Demo {
static int a = initA(); // 隐式块 #1
static { System.out.println("block 2"); } // 显式块 #2
static { System.out.println("block 3"); } // 显式块 #3
static int b = initB(); // 隐式块 #4
static int initA() { System.out.println("init A"); return 1; }
static int initB() { System.out.println("init B"); return 2; }
}
编译后执行 javap -c Demo，你会看到 <clinit> 内指令序列是：
→ 调用 initA() → 打印 "init A" → 赋值给 a → 打印 "block 2" → 打印 "block 3" → 调用 initB() → 打印 "init B" → 赋值给 b
这个顺序与源码逐行位置完全一致，毫无例外。
继承场景下父子类的 clinit 执行不等于编译合并顺序
注意：<clinit> 的**编译合并顺序**（即字节码里怎么拼的）和 **JVM 运行时调用顺序**（谁先执行）是两件事。
- 子类的
<clinit>总是在父类之后被 JVM 调用，这是类加载规范强制的 - 但父类自己的多个静态块，仍按父类源码顺序合并；子类自己的多个静态块，也仅按子类源码顺序合并
- 也就是说，编译器只管“本类内怎么拼”，JVM 管“谁先跑”——两者分层独立
常见误判点：静态块里调用非静态成员会编译失败
静态块属于类初始化阶段，此时对象尚未创建，this 不存在，实例字段和方法不可见。
- 写
System.out.println(name);（name是普通字段）→ 编译报错：non-static variable name cannot be referenced from a static context - 这种错误在编译期就拦截，根本不会进入字节码合并流程，所以不会出现在
<clinit>中 - 它提醒你：静态块只能操作静态成员、调用静态方法、创建新对象——这些才是合并逻辑的合法输入
