真实异常是堆栈最底下的“Caused by:”行；ExceptionInInitializerError只是JVM包装的外壳，需据此定位原始错误（如UnsupportedCharsetException），而非处理该包装异常本身。
直接看堆栈最底下的 Caused by: 行，它才是真实异常；ExceptionInInitializerError 本身只是 JVM 包装出来的“壳”。
怎么看日志里真正的错误源头
IDE 或控制台打印的堆栈通常以 ExceptionInInitializerError 开头，但关键信息藏在最后一段 —— 那行带 Caused by: 的输出。比如：
Exception in thread "main" java.lang.ExceptionInInitializerError
at com.example.App.main(App.java:10)
Caused by: java.nio.charset.UnsupportedCharsetException: Big5
at java.base/java.nio.charset.Charset.forName(Charset.java:528)
at org.apache.poi.util.StringUtil.<clinit>(StringUtil.java:39)
这里真正要修的是 UnsupportedCharsetException: Big5，不是 ExceptionInInitializerError。它说明类 StringUtil 在静态初始化时调用了 Charset.forName("Big5")，而当前 OpenJDK（尤其是较新版本）默认不支持 Big5 字符集。
- 如果日志没显示
Caused by:，说明异常被吞了或没完整输出 —— 尝试加 JVM 参数-XX:+PrintClassHistogram或用 IDE 调试模式启动，在类加载器处设断点 - 编译时报错（如 IDEA 编译窗口出现
java.lang.ExceptionInInitializerError），去查build-log目录下的完整日志文件，那里才有底层 cause - Android 或旧环境可能截断堆栈，此时需在最小复现类里手动加
System.out.println，确认静态块执行到哪一行就中断
OpenJDK 特定场景：字符集、模块、内部 API 失效
OpenJDK 从 11 开始移除部分字符集和内部 API，很多 ExceptionInInitializerError 实际是兼容性断裂导致的：
-
UnsupportedCharsetException（如Big5、MS950）：OpenJDK 默认只启用基础字符集；可加启动参数-Dfile.encoding=UTF-8避免隐式触发，或改用StandardCharsets.UTF_8 -
NoClassDefFoundError或ClassNotFoundException包含javax.xml.bind、sun.misc.BASE64Encoder：这是 JDK 模块化（JPMS）后移除了这些类；需显式添加依赖（如jaxb-api）或替换为java.util.Base64 -
LinkageError类型嵌套在Caused by:里：常见于 Lombok、ASM、字节码增强工具与 OpenJDK 版本不匹配；检查lombok.version是否支持当前 JDK，清理 Maven 本地仓库中冲突的 jar
为什么静态块崩了整个类就废了
Java 规范规定：类一旦初始化失败，状态变为“错误态”，后续任何对该类的主动引用（new、static 字段访问、Class.forName()）都会立即抛出同一个 ExceptionInInitializerError，不会重试也不会重新初始化。
- 这意味着你不能靠“多试几次”绕过问题；必须定位并修复原始异常
- 父类静态初始化失败时，子类根本不会开始初始化 —— 如果报错堆栈指向子类某行，先检查父类的静态块和
static final字段 -
static final字段若依赖外部资源（如Files.readString(Paths.get("conf.txt"))），哪怕文件只缺一次，该类就永久不可用
别在 static 块里干的事，现在就得改
OpenJDK 环境下，静态初始化阶段更脆弱 —— 字符集缺失、模块隔离、类加载器策略收紧，都让原来“能跑”的代码突然崩。稳妥做法是把高风险逻辑移出 static{}：
- 数据库连接、HTTP 客户端、线程池：改用懒加载单例（
static Holder模式或volatile + double-check） - 读配置、解析 JSON/YAML：放到首次调用的方法里，而不是类加载时硬扛
- 调用
Class.forName()或反射：确保目标类存在且其自身初始化也安全，否则会连锁失败 - 依赖系统属性或环境变量：加空值校验，别直接
throw new RuntimeException(...)，至少给个 fallback
真正难排查的，往往不是 Caused by: 明确指出的那行，而是它调用链上游某个看似无害的 static final 字段 —— 那个字段的初始化表达式里，藏着一个没显式 try-catch 的 IOException。
