背景
因为业务需求，mentor想要某些 bean 启动时优先加载，将数据存入缓存，便问我，“能不能调下Bean初始化顺序？”，于是便有了这篇文章
结构演示
目前一共有两个 service ，每个 service 都有一个 init 方法，打印bean创建时机，正常状态打印结果如下：
正文
方案一 ( @Order )
这是第一个想到的方法，我们给每个service上加上@Order，让他们倒序创建
代码：
结果：
嗯？不是数字越低优先级越高吗，结果怎么还是 1 -> 2？相信眼尖的人已经看出来了，我在开头埋了个坑，用 @PostConstruct 作初始化操作
题外话( @PostConstruct 和 @Order 优先级)
- @PostConstruct 修饰的方法会在服务器加载Servlet的时候运行，并且只会被服务器执行一次，也就在依赖注入完成后立即调用，bean 初始化阶段执行的。
- @Order 注解用于设置组件的执行顺序，排序集合或指定某些类型的组件的优先级
@PostConstruct 方法的执行顺序是由 Spring 容器在 bean 初始化过程中自动管理的，与 @Order 注解无关。
从 SpringBoot 的 run 源码角度来看
结论
优点 ：简单明了，适用于需要简单控制初始化顺序的场景。
缺点：只适用于具有顺序的Bean，无法处理复杂依赖关系，遇到如 @PostConstruct 会失效
方案二 ( SmartInitializingSingleton )
SmartInitializingSingleton 用于在容器完成所有单例 bean 的初始化后执行一些额外的初始化工作。用这个接口应该能保证 FirstService 后创建了吧
代码：
结果：
还是不行，@PostConstruct 的东西还是先创建了，不过起码保证了 FirstService 的 afterSingletonsInstantiated 方法是所有单例 Bean 初始化之后执行的。
不过毫无疑问，被驳回了，还说这要是有三个或多个 Bean 有这业务怎么办
结论
优点 ：确保所有单例bean都初始化，适合在所有Bean创建后执行全局初始化逻辑。
缺点：不适合控制特定Bean之间的初始化顺序。
方案三 ( @DependsOn )
既然加载顺序不行，还要有多个 Bean ，那就从 Bean 间的依赖入手嘛
代码：
结果：
不出意外的成功了，但是mentor嫌耦合性太高，一处改了处处改，后期项目大了找不到不方便维护
结论
优点 ：简单明了，适用于明确的依赖关系。
缺点：依赖关系硬编码在配置类中，灵活性较低，耦合性高。
方案四 ( 自定义 Bean 初始化类 )
那好嘛，那自定义呗
代码
在 META-INF 的 spring.factories 加上配置
org.springframework.context.ApplicationContextInitializer=\com.hhh.init.MyBeanInit
解释：
- 该自定义类 MyBeanInit 分别继承了 BeanDefinitionRegistryPostProcessor 和 ApplicationContextInitializer ，重写其内部方法BeanDefinitionRegistryPostProcessor ：提前注册或修改 Bean 定义，在所有其他 BeanFactoryPostProcessor 运行之前执行，允许我们注册或修改 BeanDefinitionApplicationContextInitializer ：初始化应用上下文，在应用上下文刷新之前调用，可以动态地为应用上下文添加属性、BeanFactoryPostProcessor 或其他配置。
- 在 postProcessBeanDefinitionRegistry 方法中，使用 BeanDefinitionBuilder 创建了两个 AbstractBeanDefinition 实例，分别对应 ThirdService 和 SecondService 类，然后，将这些 Bean 定义注册到 Spring 容器中，分别命名为 "thirdService" 和 "secondService"。
- 在 initialize 方法中，将当前的 BeanDefinitionRegistryPostProcessor 实例（ MyBeanInit 自身）添加到应用上下文的 BeanFactoryPostProcessor 列表中。在容器启动时，postProcessBeanDefinitionRegistry 方法将被调用，从而注册我们在上面定义的 Bean。
简而言之：自定义 Bean 注册方法，将自己想要优先加载的 Bean 塞进去，再加入上下文中加载
这里我们也可以把 @Component 去掉，因为在自定义初始化类中加载了，不需要被 ComponentScan 再扫描注册一次，以免出现重复注册异常
结果
结论
优点 ：灵活性高，可以用于复杂的初始化逻辑。
缺点 ：需要手动管理Bean的初始化顺序，代码维护成本较高。