为什么Spring在一台机器上出现循环依赖问题，而不是在另一台机器上？

我在获取基于Spring Data的应用程序在我的环境中运行时遇到了问题。我正在运行Debian，但我的同事要么使用Mac，要么使用Ubuntu。我在环境变量中没有进行任何特殊设置，并且使用与其他人完全相同的Java版本。

我在日志中看到了这一点，这表明这是一个导致实例化失败的循环引用问题：

nested exception is
org.springframework.beans.factory.BeanCreationException: Error
creating bean with name 'flyway.CONFIGURATION_PROPERTIES':
Initialization of bean failed;
...
nested exception is
org.springframework.beans.factory.BeanCurrentlyInCreationException:
Error creating bean with name 'flyway': Requested bean is currently in
creation: Is there an unresolvable circular reference?

因此，问题似乎是飞行方式需要一些依赖性，并且需要飞行方式。

问题是，为什么这只发生在我的环境中，而不是发生在其他人身上？即使在内存中使用H2的测试中，我也看到了问题，因此不是我的数据库有故障。

是否有可能Spring自动布线以某种方式混淆，并试图以错误的顺序做事，以便存储库在尝试设置时为空？

Spring 是否有一个用于排序依赖关系的实现不良的拓扑排序？

为什么它会在我的环境中表现不佳？

类路径的顺序会影响其行为吗？

======================

应用程序将不会启动并显示以下错误：

Caused by: org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'contentItemRepository': FactoryBean threw exception on object creation; nested exception is java.lang.IllegalArgumentException: Repository interface must not be null on initialization!
    at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.doGetObjectFromFactoryBean(FactoryBeanRegistrySupport.java:175)
    at org.springframework.beans.factory.support.FactoryBeanRegistrySupport.getObjectFromFactoryBean(FactoryBeanRegistrySupport.java:127)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getObjectForBeanInstance(AbstractBeanFactory.java:1517)
    at org.springframework.beans.factory.support.AbstractBeanFactory.doGetBean(AbstractBeanFactory.java:251)
    at org.springframework.beans.factory.support.AbstractBeanFactory.getBean(AbstractBeanFactory.java:194)
    at org.springframework.beans.factory.support.DefaultListableBeanFactory.findAutowireCandidates(DefaultListableBeanFactory.java:1127)

============================

内容项存储库签名是：

@Repository
@Transactional
public interface ContentItemRepository extends JpaRepository<ContentItem, String>, JpaSpecificationExecutor<ContentItem> {

============================

这曾经对我有用，我能够通过迭代所有提交，执行mvn干净安装并尝试启动服务器来识别破坏构建的提交，直到我找到破坏它的增量。

不能为 null 的“contentItemRepository”是这个：

@Component
+public class UrlAliasRequestConverter implements Mapper<UrlAliasRequest, UrlAlias> {
+
+    /**
+     * The content item contentItemType repository.
+     */
+    @Autowired
+    private ContentItemRepository contentItemRepository;