SpringBoot自动装配定义先后顺序失效原因极其解析

1、场景分析
- 1.1、问题总结
2、使用`@AutoConfigureBefore`、`@AutoConfigureAfter`和`@AutoConfigureOrder`注解指定加载顺序
- 2.2、@AutoConfigureXX注解失效原因总结
3、使用静态内部装配类提升加载顺序
4、bean加载顺序规则

1、场景分析

遇到的场景：
最近写定义依赖时，需要结合SpringMvc的WebMvcConfigurationSupport扩展异常解析器方法extendHandlerExceptionResolvers

	@Beanpublic HandlerExceptionResolver handlerExceptionResolver(@Qualifier("mvcContentNegotiationManager") ContentNegotiationManager contentNegotiationManager) {List<HandlerExceptionResolver> exceptionResolvers = new ArrayList<>();configureHandlerExceptionResolvers(exceptionResolvers);if (exceptionResolvers.isEmpty()) {addDefaultHandlerExceptionResolvers(exceptionResolvers, contentNegotiationManager);}extendHandlerExceptionResolvers(exceptionResolvers);HandlerExceptionResolverComposite composite = new HandlerExceptionResolverComposite();composite.setOrder(0);composite.setExceptionResolvers(exceptionResolvers);return composite;}

其中extendHandlerExceptionResolvers方法提供了可继承的接口，让开发者能够添加自定义的异常解析器放到HandlerExceptionResolverComposite中供dispatchServlet解析异常

1.1、问题总结

自定义的异常解析器配置类继承WebMvcConfigurationSupport类重写extendHandlerExceptionResolvers方法后，按照开放接口的原理，我们的异常解析器会添加到HandlerExceptionResolverComposite列表中，但是实际上并非如此。

开发者自定义的装配类和WebMvcConfigurationSupport引用的jar包中装配类顺序
解决方案一：使用@AutoConfigureBefore、@AutoConfigureAfter和@AutoConfigureOrder注解指定加载顺序
解决方案二：使用静态内部装配类提前加载

2、使用`@AutoConfigureBefore`、`@AutoConfigureAfter`和`@AutoConfigureOrder`注解指定加载顺序

SpringBoot下可以通过@Configuration自动扫描配置类和spring.factories来加载配置类，但这两种方式都无法控制加载顺序。

此时，可通过在配置类上增加@AutoConfigureAfter 、 @AutoConfigureBefore和@AutoConfigureOrder来控制配置文件加载的相对顺序。

SpringBoot的自动配置是通过spring.factories来指定的，它的优先级最低，加载时间最晚，spring.factories中的配置类顺序不代表实际加载顺序。可结合 @AutoConfigureAfter 和 @AutoConfigureBefore注解控制配置类的相对加载顺序。

通过@Configuration和@ComponentScan扫描加载的配置类，一般是我们自定义的配置类，这部分配置类优先级最高，加载时间最早，在加载spring.factories配置类前加载，但加载顺序不定。
这里就存在另一个易错点。简单的理解，当配置类在Spring扫描路径里面（scanBasePackages）会优先解析，后面在通过ImportSelector（spring.factories加载就是通过实现这个接口加载的配置类）加载进来的配置类就不会处理了，相当于一个类有两种加载方式，谁先加载谁就厉害。。。这里加载都会调用到processConfigurationClass()方法，这个下面会说！！！！

空口无凭上菜：ConfigurationClassParser–>doProcessConfigurationClass()方法加载顺序是@ComponentScan(扫描文件路径，路径里面元注解为@Component（@Cofiguration元注解也是@Component）都会被扫描到)—>加载@Import注解（配合ImportSelector接口）—>加载 @ImportResource—>加载@Bean—>…
大致顺序理清楚了。
也就是：通过spring.factories加载的配置类优先级更低，我们自定义的装配类最后才会加载

2.2、@AutoConfigureXX注解失效原因总结

extendHandlerExceptionResolvers方法在WebMvcConfigurationSupport加载的时候已经执行过了，由于加载顺序问题，那么我们自己的装配类中重写方法，将无法被调用；所以这就是@AutoConfigureBefore、@AutoConfigureAfter和@AutoConfigureOrder注解无法生效的原因，不适用很多场景

3、使用静态内部装配类提升加载顺序

这也是小编使用的方法，这种场景在纯Spring环境下我们几乎遇不见，缘由是在Spring下所有的配置文件都是我们手动确定和编写，所以“哪些能写、哪些不能写，哪些在前，哪些在后”均是确定的，由我们程序员自行控制。该场景在Spring Boot场景下被大量用到
在这里插入图片描述总结如下：

static加在bean注册方法上

1、 @Configuration配置类最优先被初始化，才会继续初始化其里面的@Bean；若有多个 @Configuration配置类，顺序由你构造AnnotationConfigApplicationContext时传入的顺序为准（若是被scan扫描进去的，则无序）

2、 @Bean方法上加static成为静态方法，并不能提升此Bean的优先级
主要是因为@Bean的解析，必须是发生在@Configuration配置类被实例化后，因此它并不能提升优先级

static加在静态内部类上

1、 @Configuration（外层）配置类的初始化顺序依旧是按照AnnotationConfigApplicationContext的定义顺序来的；对于内部类的@Configuration的初始化（不管是静态还是非静态），也依旧是外部的@Configuration完成后才行
2、 内部类里的@Bean的优先级均高于外层定义的@Bean，同时可以看到static静态内部类能够提升优先级，它比非静态内部类的优先级还高
3、内部类有限原则它只作用于本@Configuration类，也就是说仅在本主类内提升优先级。另外若出现多个内部类，按照定义顺序执行（static永远高于非static哦）
4、内部类的访问权限无所谓，private都行。