如何解决Gradle多项目中A与B的循环依赖启动问题

这种场景其实挺常见的——比如A是Web服务器/框架，B是它的插件或扩展实现，B需要依赖A的API来编写，但A运行时又需要加载B的实现。直接加依赖肯定会触发循环依赖报错，下面给你两种可行的方案，按推荐程度排序：

方案一：拆分公共API模块（最推荐） #

这是最干净的解决方式，从根源上消除循环依赖：

• 新建一个子项目C，把A中被B依赖的所有类、接口、注解等公共API都迁移到这里
• 调整三个项目的依赖配置：
  • 在A的build.gradle中：

    dependencies {
        // A依赖公共API模块
        implementation project(':C')
        // A运行时需要加载B，添加运行时依赖
        runtimeOnly project(':B')
    }
    

  • 在B的build.gradle中：

    dependencies {
        // B编译需要公共API模块的代码
        implementation project(':C')
    }
    

  • 子项目C的build.gradle无需依赖任何其他子项目

最终结构变成A ← C → B，完全没有循环依赖，同时代码职责划分更清晰，公共API的维护也更独立。

方案二：利用Gradle依赖配置 + 动态加载机制（不拆分模块的情况） #

如果暂时不想拆分模块，核心前提是A在编译阶段完全不直接引用B的代码——也就是A通过反射、SPI（服务提供者接口）等动态方式加载B的实现。具体配置如下：

1. 先配置B的依赖：B编译需要A的代码，在B的build.gradle中添加：

   dependencies {
       implementation project(':A')
   }
   

2. 再配置A的依赖：A仅运行时需要B，编译期无需感知B的存在，在A的build.gradle中添加：

   dependencies {
       runtimeOnly project(':B')
   }
   

3. 关键注意点：A的源码里绝对不能直接引用B的类（比如import com.example.BImpl或直接new BImpl()），必须用动态加载方式，比如：

   • 使用Java SPI：在B的src/main/resources/META-INF/services/目录下创建对应接口的文件，写入B实现类的全限定名，A通过ServiceLoader加载实现
   • 手动反射：通过Class.forName("com.example.BImpl")加载类后实例化

这种方式能避开循环依赖，但缺点是增加了动态加载的代码逻辑，且编译期无法检查B的存在问题，只能在运行时发现，所以还是拆分模块的方案更稳妥。

内容的提问来源于stack exchange，提问作者Steffen Harbich