Java代码块执行顺序决定对象可用性：静态块为守门人，抛异常则对象无法创建；构造块与字段按源码顺序交错初始化，影响字段最终值；父类构造必须完成，子类对象才真正可用；局部块不参与初始化。
Java 中代码块的执行顺序直接决定了对象在何时、以何种状态变得“可用”——不是简单地 new 出来就算完成，而是必须等所有前置初始化阶段走完，this 才真正指向一个字段已赋值、逻辑已就位的完整实例。
静态块决定类是否能启动对象创建
静态代码块不参与对象构建，但它控制着整个类能否进入初始化阶段。如果某个静态块抛出异常（比如数据库连接失败、配置加载出错），JVM 会抛 ExceptionInInitializerError，后续任何 new 操作都会失败——对象根本无法开始创建。也就是说，静态块是对象可用性的“守门人”，它不初始化对象，但能阻止对象诞生。
构造代码块与字段初始化共同构成对象“可安全使用”的起点
构造代码块和显式成员变量初始化（如 String name = "default";）同属实例初始化阶段，且严格按源码顺序交错执行：
- 先执行上方字段的默认/显式初始化
- 再执行上方的构造代码块
- 接着是下方字段、再下方构造块……依此类推
这个顺序决定了对象字段的最终值。例如，若构造代码块中生成唯一 ID 并赋给 id 字段，而 String tag = "user-" + id; 写在它前面，那么 tag 会拼出 "user-null"——因为此时 id 还未被赋值。只有当字段声明在构造块之后，或构造块内显式设置该字段，对象才具备预期状态。
你接手一个需求时，是不是经常这样："改一个小字段 → 结果把不相关的代码也改了"、"需求说得很模糊 → 做着做着发现跑偏了"、"数据库加个字段 → 上线才发现漏了数据兼容"、"做了个新功能 → 一个月后自己都忘了当时怎么设计的"、"写到一半被中断 → 再回来不知道从哪继续"；这个 Skill 就是专门解决这些问题的。 它会自动探测你的项目环境（JDK、Spring Boot、ORM、数据库、前端框架），记在
立即学习“Java免费学习笔记（深入）”；
父类构造完成是子类对象可用的前提
子类对象的可用性依赖于父类初始化的完成：
- 父类构造代码块和构造方法必须全部执行完毕
- 子类的构造代码块才开始运行
- 子类构造方法体最后执行
这意味着：如果父类构造器中调用了被子类重写的方法，而该方法访问了子类自己的字段（尚未被子类构造块初始化），就会读到默认值（null、0、false）。此时对象虽已分配内存，但子类部分处于“半初始化”状态，不可安全使用。
局部块不影响对象可用性，只影响方法内变量生命周期
写在方法里的 { } 块（如 void init() { { int temp = compute(); } }）完全不参与对象初始化流程。它既不延迟对象创建，也不改变对象字段状态，只限制临时变量作用域。即使它内部抛异常，也只中断当前方法执行，不影响对象本身是否构建成功。
