引导类的名字，只是约定
Spring Boot 里常见的 XXXApplication，更多是大家约出来的写法，不是语法要求。它像个入口标识，提醒你项目从这里起步。真正起作用的，不是名字，而是这个类上挂着的 @SpringBootApplication，以及里面那个 main 方法。
// 一个典型的 Spring Boot 引导类
@SpringBootApplication
public class MyAwesomeApp {
public static void main(String[] args) {
SpringApplication.run(MyAwesomeApp.class, args);
}
}
@SpringBootApplication 里到底包了什么
这个注解看起来像一个入口开关，其实是三个注解叠在一起：
@SpringBootConfiguration：本质上还是@Configuration。引导类本身可以当配置类用，也能往容器里继续加@Bean。@ComponentScan：默认从引导类所在包开始扫，子包都会被带上。所以引导类一般放在根包里，不然组件扫描范围容易漏。@EnableAutoConfiguration：自动配置真正干活的地方。类路径里有什么依赖，Spring Boot 就据此推断该补哪些 Bean。比如加了 web starter，DispatcherServlet和内嵌 Tomcat 这些东西就会跟着起来。
SpringApplication.run() 不是一行就结束
main 方法只做了一个动作：把启动交给 SpringApplication.run()。后面那一长串流程，才是 Spring Boot 自举的核心。
启动时大致会走几步：先判断应用类型，是 Servlet、WebFlux，还是普通应用；再从 META-INF/spring.factories 里把初始化器和监听器加载出来；接着推断主类，也就是带 main 的那个引导类。
真正进入运行阶段后，Spring Boot 会先发启动事件，准备环境变量和配置文件，再创建对应的 ApplicationContext。上下文准备好以后，组件扫描、配置类解析、Bean 定义加载这些事会一起发生。最后是 refresh()，这是 Spring 最核心的一步：Bean 实例化、依赖注入、初始化、自动配置落地，基本都在这里完成。内嵌 Web 服务器也是这时候起来的。
如果项目里实现了 ApplicationRunner 或 CommandLineRunner，它们会在上下文刷新后执行。到 ApplicationReadyEvent 发出来，应用才算真的可用了。
还能手动定制启动过程
如果默认启动方式不够用，可以自己 new 一个 SpringApplication 出来改配置。这个场景不算多，但在需要关掉 Banner、改默认端口、塞自定义监听器时挺顺手。
@SpringBootApplication
public class {
{
();
app.setPrimarySources(Set.of(CustomizedApp.class));
app.setBannerMode(Banner.Mode.OFF);
app.setDefaultProperties(Collections.singletonMap(, ));
app.addListeners( ());
app.run(args);
}
}
