Spring Boot 启动引导类：命名约定与底层真相

当调用 run 方法时，会先创建一个 SpringApplication 实例。在这个构造函数中，Spring Boot 会完成一系列'侦查'工作：

1. 推断应用类型：检查类路径下是存在 DispatcherServlet（传统 Servlet）还是 DispatcherHandler（WebFlux），从而确定应用类型是响应式 Web 还是 Servlet Web，抑或是非 Web 应用。
2. 加载初始化器：从 META-INF/spring.factories 文件中加载所有配置的 ApplicationContextInitializer。这些初始化器用于在 Spring 容器刷新前对其进行定制。
3. 加载监听器：同样从 spring.factories 中加载所有配置的 ApplicationListener。这些监听器会监听启动过程中的不同阶段事件，并执行相应动作。
4. 推断主启动类：通过堆栈信息找到含有 main 方法的类，也就是我们的引导类。

3.2 运行阶段：正式开演

初始化完成后，真正的 run() 逻辑开始执行，整个过程充满了事件驱动。

• ApplicationStartingEvent：发布应用启动事件。
• 准备环境 prepareEnvironment()：创建 Environment 对象，并加载系统环境变量、JVM 参数以及最重要的 application.properties/yml 配置文件。完成后发布 ApplicationEnvironmentPreparedEvent。
• 创建上下文 createApplicationContext()：根据初始化阶段推断的应用类型，创建对应的 ApplicationContext（IoC 容器）。例如，对于 Servlet Web 应用，会创建 AnnotationConfigServletWebServerApplicationContext。
• 准备上下文 prepareContext()：将 Environment 绑定到上下文，执行所有已加载的 ApplicationContextInitializer，并通过 @ComponentScan 将引导类本身作为一个配置源，将其 Bean 定义加载到容器中。之后发布 ApplicationPreparedEvent。
• 刷新上下文 refreshContext()：这是 Spring 框架最核心的方法。它会完成所有 Bean 的实例化、依赖注入、初始化，以及最重要的——触发自动配置。Tomcat 等内嵌 Web 服务器也是在此步骤中启动的。
• 启动后动作 afterRefresh()：执行所有实现了 ApplicationRunner 和 CommandLineRunner 接口的回调类，用于执行启动后的初始化任务。
• ApplicationReadyEvent：发布应用已准备就绪事件，应用正式对外提供服务。

4. 进阶探索：引导类还可以这样玩

除了最简单的 SpringApplication.run()，我们还可以通过创建和定制 SpringApplication 对象来实现更精细的控制。

@SpringBootApplication
public class CustomizedApp {
    public static void main(String[] args) {
        // SpringApplication app = new SpringApplication(CustomizedApp.class);
        SpringApplication app = new SpringApplication();
        app.setPrimarySources(Set.of(CustomizedApp.class));
        app.setBannerMode(Banner.Mode.OFF); // 关闭 Banner
        app.setDefaultProperties(Collections.singletonMap("server.port", "8081")); // 设置默认端口
        // 添加自定义监听器
        app.addListeners(new MyApplicationListener());
        ConfigurableApplicationContext context = app.run(args);
        // ... 可以获取 context 做一些事情
    }
}

5. 终极揭秘：Jar 包启动的'障眼法'

当我们把 Spring Boot 项目打成可执行 Jar 包并运行（java -jar myapp.jar）时，引导类的角色变得更加有趣。你可能会想，我明明设置了 MyAwesomeApp 作为主类，为什么启动时还能看到 Spring Boot 的 Banner？

答案是，真正的'引导'另有其人。Spring Boot 的 Jar 包结构是特殊的，它的 META-INF/MANIFEST.MF 文件里定义了真实的入口：

Main-Class: org.springframework.boot.loader.launch.JarLauncher
Start-Class: com.example.myproject.MyAwesomeApp

• Main-Class：这里配置的是 JarLauncher，它是 Spring Boot 自己提供的引导程序。它的工作是创建自定义的类加载器，从 Jar 包内部的 BOOT-INF/lib 目录下加载所有依赖的 Jar 包。
• Start-Class：这里才指向我们编写的引导类 MyAwesomeApp。JarLauncher 在准备好类加载器后，会通过反射调用 MyAwesomeApp 的 main 方法，从而正式启动我们的 Spring Boot 应用。

所以，从物理 Jar 包层面看，真正的'引导类'是 JarLauncher；而从业务逻辑层面看，MyAwesomeApp 仍然是当之无愧的'启动引导类'。这是一种巧妙的分层设计。

总结

现在我们可以清晰地回答你的问题了：

1. 命名约定：XXApplication 是官方推荐的命名习惯，但不是强制规定。
2. 本质核心：引导类的本质是一个被 @SpringBootApplication 注解标记的配置类，它作为组件扫描和自动配置的起点。
3. 启动原理：引导类通过 SpringApplication.run() 触发一系列复杂的初始化、事件发布和容器刷新流程，最终启动内嵌服务器，完成应用自举。
4. 终极真相：在打包成可执行 Jar 后，物理上的引导类是 JarLauncher，它负责创建环境并调用我们定义的业务引导类。