Java字段初始化顺序为：静态成员类加载时初始化；实例字段按声明顺序默认初始化→显式初始化→构造器赋值，其中默认值为null/0/false/‘\u0000’，局部变量无默认值；静态初始化仅一次，独立于实例。
显式初始化和默认初始化不是“先后两次赋值”，而是 JVM 分配内存后的固定流程
Java 中字段的“默认初始化”不是可选行为，也不是编译器插入的代码；它是 JVM 在对象内存分配后、任何 Java 代码执行前，对堆中字段区域做的一次统一零值填充（zero-initialization）。这个动作发生在 new 指令返回对象引用之前，由 JVM 直接操作内存完成。显式初始化（比如 private int x = 42;）则被编译器挪进构造器字节码，在默认初始化之后、构造器方法体执行之前按源码顺序逐行运行。
这意味着：即使你写 private int x = 0;，JVM 也先把它设为 0（默认），再执行一次赋 0（显式）——看似冗余，但语义上不可省略，因为显式初始化可能依赖前面字段的值或调用方法。
局部变量没有默认初始化，未赋值就用会直接编译失败
这是最容易混淆的点：成员变量（实例/静态）有默认值，局部变量没有。原因在于 JVM 对栈帧的处理方式不同——栈帧创建时所有 slot 已分配，但 JVM 不会对它们做零值填充，编译器必须在字节码校验阶段确认每个局部变量在读取前已被明确赋值。
-
int x;在方法里声明后直接return x;→ 编译报错variable x might not have been initialized -
Integer y;同样不能直接System.out.println(y);，哪怕它是个包装类 - 而
private Integer z;在类里声明，new X().z就是null，不会报错
静态变量的“准备”和“初始化”阶段严格分离
静态变量的生命周期由类加载过程控制，分两个硬性阶段：prepare（准备）和 clinit（类初始化）。前者由 JVM 在方法区（或元空间）分配内存并设默认值（如 static int a; → a == 0）；后者才执行 static { ... } 和 static int b = 5; 这类显式逻辑。
关键区别在于：如果类加载中途失败（比如 clinit 抛异常），prepare 阶段已分配的空间会被丢弃，但某些副作用（如已执行的 static 块中修改了其他类的静态字段）无法回滚。
所以不要在 static 块里做不可逆操作，尤其涉及外部状态变更。
构造器里对字段重新赋值，不等于覆盖“默认初始化”
构造器中写 this.x = 100; 看似是“第二次赋值”，其实它只是普通字段写入操作，和默认初始化毫无关系。JVM 并不记录“这是第几次写”，只保证：在构造器开始执行时，所有字段已有确定初始值（来自默认初始化），后续显式逻辑才能安全读写它们。
容易踩的坑：
- 在构造器中调用可能被子类重写的方法（
this.init();），此时子类字段尚未执行默认初始化（更别说显式初始化），读到的是零值或null - 在字段显式初始化块中调用虚方法，同上，子类字段仍为空
- 把
final字段的赋值放在构造器末尾，但中间抛异常 → 字段未被正确初始化，JVM 会拒绝该对象引用（java.lang.VerifyError或运行时异常）
真正复杂的地方不在“做了什么”，而在“谁在什么时候触发了哪一步”——JVM 的内存分配、零值填充、字节码合并、类加载阶段推进，全都是隐式发生的。一旦脱离这个链条去猜变量值，就容易掉进 null 或 0 的陷阱里。
