classcircularityerror是jvm在类加载静态初始化阶段检测到隐式闭环时抛出的error，非继承错误也非编译期可发现；其根源是static块或static final字段初始化时跨类访问未完成初始化的类，导致执行链闭环。
ClassCircularityError不是继承错误，也不是编译期能发现的“循环继承”问题——Java编译器会直接拒绝类A继承类B、类B又继承类A这类写法。它本质是**类加载阶段静态初始化过程中形成的隐式闭环**，JVM在执行<clinit></clinit>时检测到自己正在初始化又被自己触发，于是抛出Error（注意：是Error，不是Exception，无法用catch(Exception)捕获）。
静态初始化逻辑必须无跨类强依赖
这是最核心的预防原则。只要一个类的static块或static final字段初始化表达式中，直接访问了另一个尚未完成初始化的类的静态成员，风险就已埋下。
- 避免写类似
static String NAME = B.PREFIX + "_A";，尤其当B.PREFIX本身又依赖A时 -
static final字段尽量只用字面量、常量表达式或本类计算值，不引用其他类的静态字段或方法 - 枚举类要特别小心：每个枚举常量的初始化可能隐式触发其他类的
static块
把静态耦合下沉到运行时
把“必须在类加载时就确定”的假设去掉，多数循环依赖就能自然解开。
- 把
static字段改为普通实例字段，依赖通过构造函数或setter注入 - 把静态工具方法改为实例方法，或封装进单例服务中，首次调用时再初始化依赖
- 用
Supplier<t></t>或懒加载容器（如AtomicReference）延迟获取对象，而不是在static块里直接new
用接口或协调类解耦双方静态逻辑
当两个类确实需要共享某些配置或元数据时，不要让它们互相读取对方的static字段，而是引入第三方角色。
- 定义一个
ConfigHolder接口，由独立的DefaultConfig实现，A和B都只依赖这个接口 - 把原本分散在A、B中的静态常量统一收口到一个
Constants类中，且该类不依赖A或B - 在Spring等容器中，用
@PostConstruct替代static块做初始化，由容器控制顺序
构建与测试阶段主动拦截
靠人眼审查很难发现深层静态依赖，需借助工具提前暴露。
- 启用JVM参数
-XX:+TraceClassInitialization跑单元测试，观察是否有类被重复请求初始化 - 用Maven的
maven-dependency-plugin分析analyze-deps，识别模块间可疑的双向依赖 - 在CI流程中加入静态分析检查，例如用ArchUnit编写规则：禁止
static字段引用其他业务类的static成员
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
