Spring Boot的自动装配中的@ConditionalOnBean条件装配注解在Spring启动过程中，是如何保证处理顺序靠后的

前言

        为什么Spring Boot条件注解那么多，而标题中是@ConditionalOnBean呢？

        因为，相比之下我们用的比较多的条件装配注解也就是@ConditionalOnClass、@ConditionalOnBean了，而@ConditionalOnClass对顺序并不敏感（说白了就是判断类加载器是否可以在其路径下加载到Class，所以和Spring的处理顺序没啥关系），但是@ConditionalOnBean就不同了，如果顺序无法保证，那么自动装配中的@ConditionalOnBean就可能会失效。

        还有一点需要强调一下，正如Spring Boot官方建议的那样，请在自动装配类中使用条件装配注解，不要在自己定义普通配置类（普通配置类指的是我们自定义的@Configuration配置类）中使用，在普通配置类中使用条件装配注解，能不能生效那就看命了，尤其是@ConditionalOnBean这种对顺序敏感的注解；可能会出现在IDE中生效，但是到了线上就不生效了，因为你光靠ClassLoader的加载顺序是不靠谱的，在不同的操作系统环境下，class文件的加载顺序存在不确定性，文件是由文件系统管理，不同的文件管理系统有不同的机制。

可能有些人会想，我自定义@Configuration的普通配置类，我自己来显示的控制加载顺序，不过有一点请注意，你要控制的是BeanDefinition的注册顺序，而不是Bean的注入顺序；

我能想到的唯一可以控制BeanDefinition注册顺序的方式就是：自定义一个实现BeanDefinitionRegistryPostProcessor接口的实现类，并且还要实现PriorityOrder接口，要保证顺序比ConfigurationClassPostProcessor靠前，这样才有机会提前注册BeanDefinition到容器中；当然你也可以定义一个ApplicationContextInitializer接口实现类，然后通过initialize方法将自定义的BeanDefinitionRegistryPostProcessor接口的实现类添加到容器中，这样不用实现PriorityOrder接口也可以保证在ConfigurationClassPostProcessor前面执行。

不过上面说的BeanDefinitionRegistryPostProcessor接口实现类向容器添加BeanDefinition属于歪门邪道吧，明明正常扫描@Configuration注解来注册的配置类，非要把@Configuration注解去掉或者放到@ComponentScan扫不到的包下，然后由BeanDefinitionRegistryPostProcessor接口硬编码注入，应该也没有人会这么编码