Spring Boot 启动引导类：命名约定与底层启动原理

引导类的命名约定与本质

Spring Boot 提倡'约定优于配置'，XXXApplication 这种命名方式主要是为了统一识别。它就像项目的入口路牌，告诉开发者：'嘿，项目的起点就在这里！'

所以回答标题的问题：在约定上是的，但在语法上不是。它的真实身份只是一个被 @SpringBootApplication 标记且包含 main 方法的普通 Java 类。

核心注解拆解

引导类的强大源于 @SpringBootApplication。这是一个组合注解，相当于开启 Spring Boot 世界的钥匙：

• @SpringBootConfiguration：本质是 @Configuration 的'马甲'。这意味着引导类本身就是一个配置类，你可以在这里通过 @Bean 向容器注册额外的 Bean。
• @ComponentScan：即组件扫描。默认扫描范围是引导类所在包及其所有子包。这也是为什么通常建议将引导类放在项目根目录（如 com.example.myproject），以便自动发现 Controller、Service 等组件。
• @EnableAutoConfiguration：框架的灵魂所在。它会根据类路径下的依赖（比如 spring-boot-starter-web）自动推断并配置需要的 Bean。例如添加 Web Starter 后，它会自动配置 DispatcherServlet 和内嵌 Tomcat。

启动流程深度剖析

引导类的 main 方法只做了一件事：委托给 SpringApplication.run() 静态方法。这一行代码背后是一套精巧的流程，分为初始化和运行两阶段。

初始化阶段：准备舞台

调用 run 方法时，会先创建 SpringApplication 实例，完成一系列'侦查'工作：

1. 推断应用类型：检查类路径下是否存在 DispatcherServlet 或 DispatcherHandler，确定是 Servlet Web、响应式 Web 还是非 Web 应用。
2. 加载初始化器：从 META-INF/spring.factories 加载 ApplicationContextInitializer，用于在容器刷新前进行定制。
3. 加载监听器：同样从 spring.factories 加载 ApplicationListener，监听启动过程中的事件。
4. 推断主启动类：通过堆栈信息找到含有 main 方法的类。

运行阶段：正式开演

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

• ApplicationStartingEvent：发布应用启动事件。
• prepareEnvironment()：创建 Environment 对象，加载环境变量和配置文件。完成后发布 ApplicationEnvironmentPreparedEvent。
• createApplicationContext()：根据推断的类型创建对应的 ApplicationContext（IoC 容器）。
• prepareContext()：绑定环境，执行初始化器，并通过 @ComponentScan 将引导类作为配置源加载 Bean 定义。之后发布 ApplicationPreparedEvent。