静态块不能抛出受检异常，否则编译失败；若抛出未捕获异常（含runtimeexception），类初始化失败，后续所有对该类的主动使用均抛noclassdeffounderror。
静态块里直接 throw 新异常会编译失败
Java 规定 static 块中不能抛出**受检异常（checked exception）**，因为静态块没有声明 throws 的位置。你写 throw new IOException();，编译器立刻报错：unreported exception IOException; must be caught or declared to be thrown。
常见错误现象：以为加个 try-catch 就万事大吉，结果在 catch 里又 throw 新的受检异常，照样过不了编译。
- 只能 throw
RuntimeException及其子类（如IllegalArgumentException、NullPointerException） - 或者把受检异常包装成运行时异常再抛出，比如
throw new RuntimeException(e); - 别在静态块里调用可能抛受检异常的 API 而不处理——要么捕获，要么包装
类初始化失败后，后续所有对该类的主动使用都会抛 NoClassDefFoundError
这不是 ClassNotFoundException。一旦静态块执行中抛出未捕获异常（哪怕是 RuntimeException），JVM 就把该类标记为“初始化失败”，之后任何触发该类初始化的动作（比如 new 实例、访问 static 字段、调用 static 方法）都会立即抛出 NoClassDefFoundError，且异常栈里通常带 cause —— 那个原始的初始化异常。
使用场景：Spring Boot 启动时某个 Configuration 类的 static 块读配置失败，整个应用起不来，但错误日志里可能只看到 NoClassDefFoundError，真正原因被藏在 cause 里。
立即学习“Java免费学习笔记（深入）”；
- 必须检查
NoClassDefFoundError的getCause()，否则永远找不到根因 - 类加载器不会重试初始化；即使你 later 捕获了这个 Error，也无法让该类“复活”
- 反射调用
Class.forName("X")也会触发初始化，同样失败
想安全加载资源或配置？用静态方法 + 显式异常处理代替静态块
静态块适合做简单、确定成功的初始化（比如赋值常量、注册枚举）。但凡涉及 I/O、配置解析、网络、第三方库调用，就该换成懒加载的静态方法——它能声明 throws，也能被上层统一兜底。
示例对比：
public class Config {
// ❌ 静态块里读文件，失败即崩
static {
props = loadProps(); // 如果 loadProps() throws IOException，这里编译不过
}
// ✅ 改成显式方法，调用方决定怎么处理异常
private static Properties props;
public static synchronized Properties getProps() throws IOException {
if (props == null) {
props = loadProps();
}
return props;
}
}
- 静态方法可声明
throws，调用链清晰，异常可控 - 避免类在首次引用时意外挂掉，尤其对框架扫描类（如注解处理器）更友好
- 如果真需要“启动即校验”，也建议放在 main 或 Spring @PostConstruct 中，而非 static 块
静态块中调用其他类的 static 方法，要小心对方也失败
静态块执行是按类依赖顺序触发的。A 的静态块调用了 B.someStaticMethod()，而 B 的初始化本身失败了，那么 A 的初始化也会失败，并抛出 NoClassDefFoundError（cause 是 B 初始化时的异常）。
这容易形成隐式依赖链，排查时层层跳转，日志里只显示最外层的类名，根本看不出 B 才是源头。
- 不要在静态块里做跨类强依赖操作，尤其是那些自己也可能抛异常的工具类
- 如果必须调用，确保被调用类的静态初始化是幂等且高可用的（比如只含 final 字段赋值）
- JVM 不保证类加载顺序（除 direct dependency 外），多模块环境下更难预测
NoClassDefFoundError 就会一直跟着你，而且每次都是同一个 cause——只是你未必每次都会点开看。 
