Java静态初始化严格按源码顺序执行且仅一次；若某静态字段初始化触发其他类加载，原类未完成初始化的字段仍为默认值，易致空指针。
直接看静态初始化的实际执行流，别只盯着声明顺序。Java 类加载时，静态变量和静态代码块严格按源码自上而下执行，且仅一次；一旦某个静态字段的初始化表达式触发了另一个类的初始化（比如调用其静态方法或读取其静态字段），JVM 就会立即跳转过去——此时原类可能只执行了一半，被访问的字段仍是默认值（null、0、false），空指针就藏在这里。
用日志还原初始化真实路径
在每个静态变量赋值语句前、每个 static{} 块开头，加可识别的日志（推荐 System.err.println，避免被优化）：
- class A 中：
static { System.err.println("A: start init"); } static final B b = new B(); // 此行会触发 B 初始化static final String name = "A-done"; // 这行还没执行
运行后观察输出顺序。如果看到 A: start init → B: start init → B trying to access A.name → null，就锁定了循环点和失效字段。
重点检查三类隐式触发点
很多循环依赖不是明写的 A.a = B.b，而是藏在这些地方：
- 静态 final 字段右侧是方法调用，例如
static final List<String> DATA = loadFromConfig();，而loadFromConfig()内部调用了C.getInstance().getValues() - 枚举类构造器中直接引用其他类的静态字段（枚举常量初始化即触发类加载）
- 接口里定义了
static方法，该方法又访问了类 X 的静态成员；接口首次被调用时也会初始化，容易被忽略
把内联初始化换成可控的 static 块
放弃 private static final Service s = Config.getInstance().getService(); 这类黑盒写法：
- 改用
static{}块，按真实依赖顺序显式编写：先加载配置、再校验非空、再创建服务、最后赋值 - 每步加判空或断言，例如
if (config == null) throw new IllegalStateException("Config not loaded"); - 块内不调用本类尚未初始化的静态 getter 方法，防止隐式循环
定位 ExceptionInInitializerError 的真正原因
这个异常只是包装器，真正问题在 e.getCause()：
- 不要只看堆栈顶层，必须打印或调试
e.getCause()，它通常是NullPointerException - cause 的 stack trace 会精准指向某一行静态赋值语句，比如
Config.getInstance().getSerivce()—— 而getInstance()返回了null或内部抛了异常 - 若 cause 是
ExceptionInInitializerError套娃，说明循环依赖已发生，需回溯日志找第一个中断点
