ExceptionInInitializerError 是 JVM 类初始化失败的致命错误，由静态变量或块中未捕获异常引发，导致类加载中断且不可重试；其 getCause() 才是根本原因，常隐式引发 NoClassDefFoundError。
ExceptionInInitializerError 是类“胎死腹中”的错误
它不是普通异常，而是 JVM 在类初始化阶段彻底失败的信号——这个类压根没加载成功，后续任何对它的引用（哪怕只是 MyClass.class）都会直接抛出 ExceptionInInitializerError，甚至间接引发 NoClassDefFoundError。这不是你能 catch 住的运行时异常，是类加载器层面的“流产”。
静态块里 throw new RuntimeException() 就会触发
很多人以为只有显式写 static{} 才有风险，其实所有静态变量初始化语句（比如 private static int x = Integer.parseInt("abc");）都会被 JVM 自动塞进一个隐式静态初始化块，并按源码顺序执行。
- 只要其中任意一行抛出未捕获的
RuntimeException（如NullPointerException、ArithmeticException、NumberFormatException），整个初始化就中断，JVM 立即包装为ExceptionInInitializerError -
ExceptionInInitializerError的getCause()才是真凶——必须打印或调试它，否则只看到“初始化错误”，完全不知道哪行代码出了问题 - 别在静态块里调用可能抛异常的工具方法，比如
Files.readAllLines(Paths.get("config.txt"))；路径不存在？直接崩
为什么 NoClassDefFoundError 往往是它的马甲
当另一个类（比如 ServiceA）在编译期依赖了初始化失败的 ConfigUtil，而运行时首次主动使用 ServiceA 时，JVM 才去加载它——结果发现其依赖的 ConfigUtil 已经在之前加载失败、被标记为“不可用”，于是抛出 NoClassDefFoundError: ConfigUtil。日志里根本看不到 ExceptionInInitializerError，除非你翻到最早那次类加载尝试的完整堆栈。
- 排查
NoClassDefFoundError时，第一反应不该是检查 classpath，而是搜日志里有没有更早出现的ExceptionInInitializerError - IDE 启动时、Spring 容器刷新初期、或单元测试 setup 阶段，最容易暴露这类问题——因为那是大批静态类集中加载的时刻
- 如果用了模块化（Java 9+），
requires声明不会阻止初始化失败，但会让错误更隐蔽：模块加载成功，类却无法访问
修复策略：静态初始化必须“零风险”或“兜底可见”
不能靠 try-catch 把异常吞掉然后静默失败——那会导致后续 NPE 或逻辑错乱。正确做法是：要么把高危操作移出静态上下文，要么让失败可诊断、可恢复。
- 把资源加载、配置解析、连接建立等操作，推迟到第一次调用的懒加载方法里（如
public static Config getInstance()），而不是放在static字段初始化中 - 如果非得静态初始化，必须用
try-catch捕获所有可能的Exception，并至少记录原始异常：logger.error("Failed to init ConfigUtil", e);，不能只e.printStackTrace() - 避免静态字段间循环依赖：
A的静态块调B.method()，而B的静态字段又依赖A.VALUE——JVM 会卡在中间状态，抛出ExceptionInInitializerError并附带java.lang.ExceptionInInitializerError: null这种最难 debug 的空 cause
最常被忽略的一点：静态初始化失败后，该类在当前 ClassLoader 中永远处于“已加载但未初始化完成”状态，后续任何尝试都不会重试——所以修复代码后，必须重启 JVM，光 reload class 没用。
