Spring Boot升级后自定义JPA仓库循环依赖问题求助

问题根源 #

Spring Boot 2.6版本开始默认禁用了循环依赖的自动处理机制，而2.3.x版本默认允许这类依赖存在。你升级到2.7.11后，测试环境触发了之前隐藏的循环依赖检测，因此出现报错。

@Lazy是否可行？ #

@Lazy确实能临时解决问题——它延迟了Publications Bean的初始化时机，避开了启动阶段的循环依赖检查。但这只是规避手段，并非根本解决方案：延迟初始化可能导致某些场景下Bean未被正确初始化，埋下运行时隐患。

根本解决方案：修正Spring Data JPA自定义Repository的实现方式 #

你的代码里PublicationsImpl作为独立的@Repository注入Publications，这种写法不符合Spring Data JPA的自定义Repository规范，是导致循环依赖的核心原因。正确的实现方式是将自定义方法合并到Spring Data生成的Repository代理中：

步骤1：定义自定义方法接口 #

创建包含自定义业务逻辑的接口，与主Repository分离：

public interface PublicationsCustom {
    Foo someCustomOperation(String id, LocalDate xyz);
}

步骤2：让主Repository继承自定义接口 #

让你的Publications接口同时继承JpaRepository和PublicationsCustom：

public interface Publications extends JpaRepository<Publication, String>, PublicationsCustom {
    // 保留原有的JPQL查询方法
    List<Publication> findBySomeComplexQuery(Publication myStuff, LocalDate xyz);
}

步骤3：实现自定义接口（无需@Repository） #

实现类命名为PublicationsImpl（遵循主Repository接口名+Impl的命名规则，Spring Data会自动识别），不需要添加@Repository注解，也无需担心循环依赖——Spring会自动处理代理关系：

public class PublicationsImpl implements PublicationsCustom {

    private final Publications publications;

    // 构造注入Spring生成的Repository代理
    public PublicationsImpl(Publications publications) {
        this.publications = publications;
    }

    @Override
    public Foo someCustomOperation(String id, LocalDate xyz) {
        var myStuff = publications.findById(id).orElseThrow();
        // ... 原有复杂业务逻辑
        var moreStuff = publications.findBySomeComplexQuery(myStuff, xyz);
        // ...
        return ...;
    }
}

这种方式下，Spring Data会自动将自定义方法合并到Publications的代理Bean中，既消除了循环依赖，又符合Spring Data的设计规范。

总结 #

• 优先采用重构Repository实现方式的方案，从根源解决循环依赖，避免潜在风险。
• 如果暂时无法重构代码，@Lazy可以作为临时过渡方案，但建议后续尽快完成重构。

内容的提问来源于stack exchange，提问作者Archimedes Trajano