排查核心是深挖ExceptionInInitializerError的getCause()真实异常，按声明顺序检查静态字段初始化，避免运行时动态操作，用JVM参数和日志定位断裂点。
排查这类问题，核心是抓住“静态成员变量的初始化发生在类加载阶段，而运行时动态值可能在此时不可用或出错”这一关键点。不能只看 ExceptionInInitializerError 表层，必须深挖其 getCause() 返回的真实异常，并还原初始化执行顺序。
重点看堆栈里的 “Caused by:”
ExceptionInInitializerError 本身只是个包装器，真正的错误藏在它的 cause 里。常见 cause 包括 NullPointerException、IOException、IllegalArgumentException 等。
- 在日志或控制台中，务必搜索 “Caused by:”，而不是只匹配 “ExceptionInInitializerError”
- 用 IDE 调试时，在 catch 块中对异常对象调用
e.getCause().printStackTrace()，或直接查看e.getCause()的内容 - 若使用 SLF4J 或 Log4j，确保 logger.error("msg", e) 是带 Throwable 参数的重载方法，否则 cause 会被丢弃
检查静态字段赋值语句的真实执行时机
静态字段按源码中声明顺序初始化，且只能访问此前已声明并完成初始化的静态成员。运行时动态初值（如调用方法、读配置、解析 JSON）极易因依赖未就绪而失败。
- 把
private static final Service s = Config.getInstance().getService();这类内联初始化改为static{}块，显式控制顺序 - 在块内逐行初始化：先加载配置，再校验非空，最后创建服务；每步后加
if (xxx == null) throw new IllegalStateException(...) - 避免在字段初始化表达式中调用本类其他 getter 方法——它可能触发尚未完成的静态初始化，导致 NPE
识别高风险的运行时动态初值操作
以下操作放在静态字段初始化中极易失败，应优先审查：
- 调用
Class.getResourceAsStream()后未判空，直接传给Properties.load()或 JSON 解析器 - 硬编码字符串经
JSON.parseObject(str)解析，但字符串格式非法或含占位符未替换 - 访问系统属性
System.getProperty("xxx")或环境变量，但运行时未设置 - 调用第三方库的静态工厂方法（如
OkHttpClient.create()），而其内部依赖尚未初始化
用 JVM 参数和日志辅助定位
当问题偶发或环境差异大时，需借助工具确认初始化是否真正执行、在哪一步中断：
- 启动参数加
-XX:+TraceClassInitialization，JVM 会打印 “Initializing class X” 及失败时的原始异常，比堆栈更直接 - 在每个关键静态字段赋值前后加日志，例如：
log.debug("Before init dbConfig: {}", dbConfig); - 对
static{}块首行设断点，单步执行，观察各字段实时值——null 出现的位置就是断裂点
