Spring≥6.2.0下第三方库@Autowired+@Bean错误注解的处理方案咨询

问题背景 #

第三方库的DemoConfig类中，demoService()方法同时标注了@Autowired和@Bean，这种写法在Spring 6.2.0之前可正常运行，但Spring 6.2.0通过BeanMethod类的校验逻辑判定@Autowired在@Bean方法上无效，导致依赖注入失败、应用崩溃。

可行处理方案 #

1. 自定义配置类覆盖原Bean定义 #

无需修改第三方库代码，自行编写配置类手动注册所需Bean，同时排除原库的DemoConfig：

@Configuration
@SpringBootApplication(exclude = DemoConfig.class) // 排除原配置类
public class CustomDemoConfig {
    @Bean
    public DemoService2 demoService2() {
        return new DemoService2();
    }

    @Bean
    public DemoService demoService(DemoService2 demoService2) {
        // 通过Spring注入DemoService2，替代原方法的直接调用
        return new DemoService(demoService2);
    }
}

该方案侵入性极低，只要原Bean构造逻辑不复杂就能快速落地，无需处理字节码相关操作。

2. Gradle构建阶段程序化修改第三方库字节码 #

这是长期来看最可靠的自动化方案——可集成到构建流程中，每次拉取第三方库新版本都会自动处理，完全避免手动重复操作。

可使用Byte Buddy或ASM的Gradle插件，在构建时修改第三方JAR中的DemoConfig类，移除demoService()方法上的@Autowired注解。示例配置（基于Byte Buddy Gradle插件）：

plugins {
    id 'net.bytebuddy.byte-buddy-gradle-plugin' version '1.14.13'
}

byteBuddy {
    transformation {
        target {
            include 'com/example/DemoConfig.class' // 替换为实际类全路径
        }
        transform {
            new AgentBuilder.Default()
                .type(ElementMatchers.named("com.example.DemoConfig"))
                .transform((builder, typeDesc, classLoader, module) ->
                    builder.method(ElementMatchers.named("demoService"))
                        .annotations()
                        .remove(ElementMatchers.named("org.springframework.beans.factory.annotation.Autowired"))
                )
        }
    }
}

该方案能解决Java Agent的核心痛点：修改的是JAR包中的实际类文件，Spring通过ASM读取类元数据时会直接拿到修改后的内容，不会出现内存字节码与磁盘类文件不一致的问题。

3. 用Spring后置处理器修正Bean定义 #

通过实现BeanFactoryPostProcessor，在Spring注册Bean定义阶段修改DemoService的依赖配置：

@Component
public class DemoBeanFixProcessor implements BeanFactoryPostProcessor {
    @Override
    public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException {
        BeanDefinition demoServiceDef = beanFactory.getBeanDefinition("demoService");
        // 重置构造参数，改为从容器中引用demoService2 Bean
        demoServiceDef.setConstructorArgumentValues(new ConstructorArgumentValues());
        demoServiceDef.getConstructorArgumentValues().addIndexedArgumentValue(0, new RuntimeBeanReference("demoService2"));
    }
}

该方案无需修改字节码，但要求对Spring的Bean生命周期和BeanDefinition结构有一定了解，若原Bean依赖关系复杂，适配成本会较高。

方案评估：Gradle构建修改字节码是否最优？ #

如果第三方库的配置类逻辑复杂（比如存在多个类似问题的方法、Bean依赖关系交织），Gradle构建阶段修改字节码是最优方案：

• 完全保留原库的Bean注册逻辑，不会因自定义配置引入兼容性风险；
• 自动化程度拉满，新版本库更新后无需手动干预；
• 彻底解决了Java Agent方案中Spring读取磁盘类文件元数据的问题。

若原Bean构造逻辑简单，自定义配置类的方案更轻量，也是不错的选择。

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