静态代码块在类首次被主动使用且jvm执行初始化阶段时执行，仅一次；按源码顺序执行，依赖声明顺序，不可用this或new实例，异常会导致初始化失败。
静态代码块什么时候执行
静态代码块在类首次被主动使用时、由 JVM 触发类加载过程的「初始化阶段」执行，且仅执行一次。它不依赖对象创建，哪怕你只引用了该类的某个 static final 常量（且该常量在编译期可确定），也可能跳过初始化，从而跳过静态代码块。
常见错误现象：Class.forName("X") 默认会触发初始化，但 ClassLoader.loadClass("X") 不会；用子类调用父类的静态字段，若该字段不是 final 或非常量表达式，会触发父类初始化（也就执行其静态代码块）。
- 只有当类处于“尚未初始化”状态，且 JVM 判定需要进行初始化时，才会执行静态代码块
- 多个静态代码块按源码出现顺序依次执行，和位置有关，不能靠“写在后面”来覆盖前面的逻辑
- 如果静态代码块中抛出未捕获异常（如
ExceptionInInitializerError），该类会进入“初始化失败”状态，后续任何对该类的主动使用都会直接抛出同一异常
静态代码块 vs 静态变量初始化顺序
Java 对静态成员的初始化顺序有严格规定：先执行父类静态内容，再执行子类；同类中，按声明顺序从上到下，静态变量赋值和静态代码块交替执行——谁在前，谁先运行。
使用场景：想确保某个配置在类加载时就完成解析并缓存，又依赖另一个静态工具类已就绪，就得注意它们的声明顺序。
立即学习“Java免费学习笔记（深入）”；
-
static int a = getValue();和static { b = compute(); }按文本顺序执行，不是“所有变量赋值完再执行块” - 若
getValue()内部访问了尚未声明的另一个静态字段，结果是默认值（如0、null），不是编译错误 - 静态 final 基本类型常量（如
static final int PORT = 8080;）属于“编译期常量”，其值在类加载前就被内联，不触发所在类初始化
为什么不能在静态代码块里用 this 或 new 实例
因为静态代码块属于类级别，在类初始化时运行，此时还没有任何实例存在，this 没有意义；而 new 某个实例虽然语法合法，但若该实例的构造过程又触发当前类的其他静态初始化（比如间接引用了本类 static 字段），可能造成循环依赖，JVM 会抛出 java.lang.ExceptionInInitializerError。
容易踩的坑：在静态块中调用某工具类的 getInstance()，而该方法内部又尝试访问当前类的某个静态字段——看似无关，实则形成隐式依赖链。
- 禁止在静态代码块中出现
this、super、非静态内部类实例化等依赖实例上下文的操作 - 可以调用其他类的静态方法，但要确认那些方法不反向依赖本类未完成初始化的部分
- 日志记录建议用简单字符串拼接，避免调用可能触发类加载的复杂格式化工具（如某些 SLF4J 绑定在首次获取 logger 时才初始化）
调试静态代码块没执行的常见原因
最典型的是你以为类被用了，其实 JVM 根本没走到初始化那步。比如只读取了一个 static final String 字段，或反射获取了 Class 对象但没调用 forName(..., true, ...) 的第三个参数设为 true。
性能影响很小，但一旦出错，错误堆栈里只会显示 ExceptionInInitializerError，根本看不到原始异常——原始异常被包装在 cause 里，必须展开看。
- 用
javap -c YourClass查看字节码，确认<clinit></clinit>方法是否存在及内容 - 启动 JVM 时加参数
-XX:+TraceClassLoading和-XX:+TraceClassInitialization，观察类是否真的初始化了 - 不要在静态代码块里做耗时操作（如网络请求、大文件读取），它会阻塞整个类的初始化，影响所有后续对该类的使用
真正麻烦的从来不是写错语法，而是初始化时机被各种间接引用绕开，或者异常被吞掉后只剩一个空泛的 ExceptionInInitializerError ——这时候得一层层翻 getCause()。
