使用@AutoConfiguration时自定义Bean未覆盖默认Bean的问题咨询

在某个Starter的自动配置模块中，原有配置如下：

@Configuration
public class AutoConfiguration {
    @Bean
    @ConditionalOnMissingBean
    public SomeBeanInterface someBean() {
        return new DefaultBean();
    }
}

使用该Starter的客户端模块中，存在自定义Bean配置：

@Configuration
public class UserConfiguration {
    @Bean
    public SomeBeanInterface someBean() {
        return new CustomBean();
    }
}

原本Spring会优先使用自定义的CustomBean而非默认的DefaultBean，但将Starter模块中的@Configuration替换为官方推荐的@AutoConfiguration后，Spring反而选择了默认Bean。

排查后怀疑和@AutoConfiguration默认的proxyBeanMethods = false有关，但存在疑惑：官方文档明确说明“自动配置类保证在所有用户自定义Bean定义添加后加载”，按此逻辑应该优先选择先加载的自定义Bean，希望解释该行为。

核心原因：@ConditionalOnMissingBean判断时机与proxyBeanMethods的影响 #

• 加载顺序≠实例判断时机
  官方文档提到的自动配置类“在用户自定义Bean定义添加后加载”，指的是自动配置类本身的类解析和Bean定义注册流程启动时间晚于用户配置类，但@ConditionalOnMissingBean的判断是在自动配置类的Bean实例化逻辑执行时触发的，而非类加载阶段。

• proxyBeanMethods的两种模式差异

  • 当使用默认proxyBeanMethods = true的@Configuration时，配置类是Spring生成的代理类，调用someBean()方法会被代理拦截：Spring会先检查容器中是否已有SomeBeanInterface类型的Bean实例，再决定是否创建新对象，这会保证自定义Bean优先被选中。
  • 而@AutoConfiguration默认proxyBeanMethods = false，此时配置类是普通Java类，someBean()方法会直接执行并创建DefaultBean实例。这个过程发生在自动配置类的Bean定义被处理时，此时用户自定义的CustomBean虽然已经完成了Bean定义的注册，但还没有被实例化——@ConditionalOnMissingBean的判断逻辑会认为容器中不存在该类型的Bean实例，因此注册了默认Bean。

• 后注册Bean无法覆盖已存在Bean
  用户自定义的Bean定义确实先被注册，但Spring的Bean实例化是按顺序执行的。当默认Bean被实例化并注册到容器后，后续自定义Bean实例化时，发现同类型Bean已经存在，默认情况下Spring不会用后注册的Bean覆盖已有的，最终容器中保留的就是默认Bean。

可行的解决方式 #

• 给自动配置类的@Bean方法添加更明确的条件：@ConditionalOnMissingBean(type = "com.example.CustomBean")，指定仅当自定义Bean不存在时才创建默认Bean；
• 在自定义的CustomBean上添加@Primary注解，强制Spring优先选择该Bean；
• 手动设置@AutoConfiguration(proxyBeanMethods = true)，恢复代理模式，但这会带来微小的性能损耗，不推荐作为通用方案。

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