Java代码块执行顺序本身不直接导致异常，但静态块或实例块中访问未初始化字段、触发循环依赖、调用子类重写方法或混入高风险操作，均会引发NullPointerException、ExceptionInInitializerError等隐性异常。
Java 中代码块执行顺序本身不会直接导致异常，但若开发者对初始化阶段的依赖关系和执行时序缺乏把控，就极易在静态块或实例块中埋下隐性异常风险——尤其是当代码块里调用未就绪的资源、访问尚未初始化的字段，或触发循环依赖时。
静态代码块里访问未初始化的静态字段
静态变量和静态块按源码顺序交替执行。若某个 static 变量赋值表达式（如 static String conf = loadConfig();）调用了后面才声明的另一个 static 字段，该字段此时仍为默认值（null 或 0），而 loadConfig() 内部若尝试解引用它，就会抛出 NullPointerException。
- 写在前面的静态块无法“预知”后面字段的值，JVM 不做推测性初始化
- 编译不报错，运行时报错，且类永久进入初始化失败状态
- 典型表现：首次 new 对象或调用 static 方法时抛 ExceptionInInitializerError
实例块中调用被子类重写的方法
实例块在父类构造器返回后、子类构造器体开始前执行，此时子类字段尚未完成默认初始化和显式赋值。若实例块里调用了可能被子类重写的方法（比如 this.init();），而该方法内部访问了子类的实例字段，那些字段值仍是默认值（null 或 0），极易引发逻辑错误或空指针。
- 看似安全的 this 在实例块中已可用，但子类状态尚未建立
- 这种设计违背了“先构造父类、再构造子类”的契约
- 调试时日志显示字段为 null，但代码里明明写了初始化语句——其实是执行时机错位
父子类静态初始化形成隐式循环依赖
当子类静态块中主动引用父类的某个非编译期常量静态字段，而该字段的初始化又反过来调用子类的 static 方法或访问子类 static 字段时，JVM 类加载器会陷入等待闭环：父类等子类初始化完成，子类又等父类初始化完成。
立即学习“Java免费学习笔记（深入）”；
- 最终抛出 java.lang.ExceptionInInitializerError，根因常是 java.lang.ClassCircularityError 或死锁
- 这类问题难以复现，多出现在模块拆分、ClassLoader 隔离或反射调用场景
- 尤其危险的是通过 Class.forName() 触发初始化，间接激活了隐藏依赖链
高风险操作混入静态块导致不可恢复失败
网络请求、文件读取、数据库连接等运行时依赖强的操作，一旦放在静态块中，就绑定到了类初始化这一不可重试的关键节点。任一环节超时、权限不足或服务不可用，都会让整个类初始化失败。
- 后续所有对该类的访问，包括 instanceof、getClass()，都会直接抛错
- 异常堆栈常掩盖真实原因，只显示 NoClassDefFoundError 或包装后的 ExceptionInInitializerError
- 正确做法是移出静态块，改用 Holder 模式或懒加载，在业务方法中捕获并重试
