引导类的命名约定与本质
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 实例,完成一系列'侦查'工作:
- 推断应用类型:检查类路径下是否存在
DispatcherServlet或DispatcherHandler,确定是 Servlet Web、响应式 Web 还是非 Web 应用。 - 加载初始化器:从
META-INF/spring.factories加载ApplicationContextInitializer,用于在容器刷新前进行定制。 - 加载监听器:同样从
spring.factories加载ApplicationListener,监听启动过程中的事件。 - 推断主启动类:通过堆栈信息找到含有
main方法的类。
运行阶段:正式开演
初始化完成后,真正的逻辑开始执行,整个过程充满事件驱动:
ApplicationStartingEvent:发布应用启动事件。prepareEnvironment():创建 Environment 对象,加载环境变量和配置文件。完成后发布ApplicationEnvironmentPreparedEvent。createApplicationContext():根据推断的类型创建对应的 ApplicationContext(IoC 容器)。prepareContext():绑定环境,执行初始化器,并通过@ComponentScan将引导类作为配置源加载 Bean 定义。之后发布ApplicationPreparedEvent。

