代码块执行顺序必须明确：静态块（S-P/S-C）、实例块（I-P/I-C）、构造器（C-P/C-C）严格按序触发；日志需带身份前缀，断点须设在各块首行，警惕非法前向引用、this()调用、init()异常及反射未触发主动使用等问题。

代码块执行顺序直接影响调试时的观察逻辑和问题定位效率。如果不清楚静态块、实例块、构造器的真实触发时机与层级关系，很容易把异常归因错误，比如把子类字段未初始化的问题误判为逻辑 bug，其实只是父类构造器里调用了被重写的方法——而此时子类实例块还没执行。

日志必须带身份标识，不能只靠时间戳

多个类、父子嵌套下，日志输出容易混在一起。光看时间先后无法判断是父类静态块还是子类实例块在运行。正确做法是给每类代码块打上明确前缀：

• [S-P] 表示父类静态块，[S-C] 表示子类静态块
• [I-P] 表示父类实例块，[I-C] 表示子类实例块
• [C-P] 表示父类构造器入口，[C-C] 表示子类构造器入口
• 字段初始化方法内加 [F-P.init] 或 [F-C.loadConfig]，避免和构造逻辑混淆

断点要配合日志，否则会漏掉异常中断路径

静态块里抛出未捕获异常，会导致类初始化失败，后续所有对该类的主动使用都会直接报 ExceptionInInitializerError。但日志可能只打印到出错前一行，你以为流程走完了，其实卡在中间。所以：

deep-java-review

Java项目代码review工具。分析Git变更+完整调用链路上下文，推断业务需求，进行多维度评分和分类汇总，生成完整PRD文档。包含细粒度Java代码审查清单（Null安全、异常处理、Streams、并发、equals/hashCode、资源管理、API设计、性能、MyBatis/ORM、事务边界、SQL/DD...

下载

• 每个静态块第一行设断点，确认是否真正执行
• 每个实例块开头也设断点，验证它是否在 super() 返回后、构造器体开始前触发
• 如果断点没命中，说明类加载被阻断或对象创建流程被跳过

执行顺序乱了，大概率不是顺序记错了，而是有隐式干扰

看到输出不符合 S-P → S-C → I-P → C-P → I-C → C-C，别急着翻书查顺序，先检查这几处：

立即学习“Java免费学习笔记（深入）”；

• 某个静态块里访问了子类的静态字段（该字段声明在后面），造成非法前向引用
• 构造器第一行用了 this(...) 而非 super(...)，导致本类构造器先跑，打破父→子链条
• 某个 init() 方法抛了异常，中断了实例初始化流程，后续代码块根本没机会执行
• 用了反射但没触发主动使用（比如只调 Class.forName("X", false, cl)），静态块压根不会跑

局部块不参与初始化，但它会让调试更难分辨作用域

写在方法里的 {...} 看起来像实例块，但它跟类加载、对象创建完全无关。调试时如果在局部块里打了日志，却误以为它属于对象初始化阶段，就会错估变量生命周期。记住：

• 局部块只随方法调用执行，哪怕类都没初始化过，只要方法进了，它就跑
• 它定义的变量出了大括号就不可见，不影响 this 指向或字段状态
• 不要在局部块里做资源释放之外的事，尤其别放可能影响对象状态的逻辑