还记得最开始接触web开发的时候，去看热门的开源项目，基本都是用的是纯正的Spring Framework，项目里充斥着山一样高的XML文件。bean、aop、tx… 每个bean的诞生，都需要你在XML里“亲笔签名”。集成一个新框架？行，先花半天时间研究它的配置说明，然后小心翼翼地把几十行XML粘贴到你的配置文件里，祈祷启动时不要因为一个小小的拼写错误而满屏飘红。

Spring本身是伟大的，但它的“伟大”也带来了“沉重”。

Spring Boot的出现，就像一个叛逆的后辈，它对前辈说：“你那套太复杂了，我来帮你搞定。” 它的核心理念不是创造新功能，而是对现有Spring生态的“智能封装”和“习惯性默认”。

它主要干了三件大事，彻底改变了游戏规则：

1. 自动配置 (Auto-Configuration)：这是它的王牌。你加个数据库驱动依赖，它就自动配好DataSource；你加个Web启动器，它就自动配好DispatcherServlet和内嵌Tomcat。
2. 内嵌Web服务器 (Embedded Web Server)：告别了笨重的WAR包和外部Tomcat。一个java -jar命令就能启动一个完整的Web应用，对微服务和云原生部署极其友好。
3. 约定大于配置 (Convention over Configuration)：它假设了大多数开发者会如何使用一个技术栈，并提供了“最佳实践”作为默认配置。比如，application.properties或application.yml就是它约定的配置文件位置。

简单说，Spring负责提供十八般武器，而Spring Boot则直接给你组装好了一把趁手的“AK-47”，你拿来就能用。

自动配置的“谍战”：@EnableAutoConfiguration背后的源码博弈

Spring Boot的自动配置魔术，其“咒语”就是启动类上的@SpringBootApplication注解。但真正的核心，藏在它所组合的@EnableAutoConfiguration里。

这个注解本身平平无奇，关键在于它通过@Import导入了一个叫AutoConfigurationImportSelector（在早期版本中是 EnableAutoConfigurationImportSelector）的类。这家伙才是真正的幕后黑手。

它的核心工作可以浓缩为一句话：去classpath下的所有jar包里，找到META-INF/spring.factories文件，并加载其中org.springframework.boot.autoconfigure.EnableAutoConfiguration键所对应的所有配置类。

（注：在Spring Boot 2.7及以后，推荐使用META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports文件，原理相通，但更高效。）

打开任何一个spring-boot-autoconfigure的jar包，你都能找到这个spring.factories文件，内容类似这样：

# Auto Configure
org.springframework.boot.autoconfigure.EnableAutoConfiguration=\
org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration,\
org.springframework.boot.autoconfigure.web.servlet.DispatcherServletAutoConfiguration,\
org.springframework.boot.autoconfigure.data.redis.RedisAutoConfiguration,
# ... a very long list

AutoConfigurationImportSelector把这一长串类名加载到内存里，然后Spring容器就会尝试去实例化它们。到这里，你可能会问：难道它会把所有这些*AutoConfiguration类都加载一遍？那项目里没用Redis，岂不是也要加载Redis的配置，然后报错？

问得好。这就是自动配置的第二层，也是最精髓的一层：条件化配置。

@Conditional：自动配置的“智能开关”

我们随便打开一个自动配置类，比如DataSourceAutoConfiguration，你会看到它的类定义上布满了@Conditional...系列的注解。

@Configuration
// 只有当classpath下存在"javax.sql.DataSource"和"org.springframework.jdbc.datasource.embedded.EmbeddedDatabaseType"这两个类时，
// 这个配置类才会生效。
@ConditionalOnClass({ DataSource.class, EmbeddedDatabaseType.class })
// 只有当容器中尚未存在一个名为 "dataSource" 的Bean时，下面的@Bean定义才会生效。
@ConditionalOnMissingBean(type = "io.r2dbc.spi.ConnectionFactory")
@EnableConfigurationProperties(DataSourceProperties.class)
public class DataSourceAutoConfiguration {

    @Bean
    // 只有当classpath下存在 HikariCP 的相关类时，这个创建Hikari数据源的方法才生效。
    @ConditionalOnClass(HikariDataSource.class)
    @ConditionalOnMissingBean(DataSource.class) // 保证用户自定义的DataSource优先
    @ConditionalOnProperty(name = "spring.datasource.type", havingValue = "com.zaxxer.hikari.HikariDataSource", matchIfMissing = true)
    public DataSource hikariDataSource(DataSourceProperties properties) {
        // ... 创建并返回 HikariDataSource
    }
}

看明白了吗？@ConditionalOnClass就像一个哨兵，它会检查你的classpath里有没有某个特定的类。如果你压根没引入mysql-connector-java.jar，那DataSource.class可能就不存在，整个DataSourceAutoConfiguration就会被跳过。

@ConditionalOnMissingBean则更像是“补位选手”。它保证了只有在你没有自己定义一个DataSource类型的Bean时，Spring Boot的自动配置才会生效。这给了你极大的灵活性——默认我全包，但你一出手，就听你的。

Spring Boot内置了大量的@Conditional注解，如：

• @ConditionalOnProperty：检查某个配置属性是否存在或等于特定值。
• @ConditionalOnBean：当容器中存在某个Bean时。
• @ConditionalOnWebApplication：当这是一个Web应用时。

正是这些“条件开关”，让Spring Boot的自动配置变得精准而智能，它只会加载你真正需要的东西。

要点速记

• @EnableAutoConfiguration是自动配置的总开关。
• AutoConfigurationImportSelector是执行者，负责从spring.factories加载候选配置。
• *AutoConfiguration类是具体的配置蓝图。
• @ConditionalOn...系列注解是决策者，决定蓝图是否生效。

main方法如何引爆内嵌Tomcat？

理解了自动配置，也就解开了“main方法启动Web项目”的谜题。

整个过程是一场由spring-boot-starter-web依赖触发的连锁反应：

1. 依赖触发：你在pom.xml中加入了spring-boot-starter-web。这个启动器默默地把spring-boot-starter-tomcat、spring-webmvc等一堆jar包带进了你的classpath。
2. 条件满足：Spring Boot启动时，@EnableAutoConfiguration开始工作。其中一个叫ServletWebServerFactoryAutoConfiguration的自动配置类，它的@ConditionalOnWebApplication和@ConditionalOnClass({ Servlet.class, Tomcat.class })条件瞬间被满足。
3. 工厂就位：这个配置类会根据classpath中存在的具体Web服务器（Tomcat, Jetty, or Undertow），为你创建一个ServletWebServerFactory的Bean，默认是TomcatServletWebServerFactory。
4. 启动服务器：在Spring容器刷新（refresh）的生命周期中，有一个onRefresh()阶段。对于Web应用，ServletWebServerApplicationContext会重写这个方法，并在其中调用createWebServer()。
5. 源码直击：在createWebServer()方法里，它会从容器中获取上一步创建的ServletWebServerFactory，然后调用它的getWebServer()方法。

// In ServletWebServerApplicationContext.java
private void createWebServer() {
    // ...
    // 获取在自动配置中创建好的工厂Bean
    ServletWebServerFactory factory = getWebServerFactory();
    // 调用工厂方法，创建并启动服务器
    this.webServer = factory.getWebServer(getSelfInitializer());
    // ...
}

TomcatServletWebServerFactory的getWebServer()方法内部，就是纯粹的Tomcat API调用：new Tomcat()，设置端口、协议，然后启动。

就这样，一个看似简单的main方法调用，通过自动配置的精密传导，最终完成了内嵌Tomcat的实例化与启动。

小结

1. 可观测性——诊断你的自动配置：当你不确定某个Bean为什么没有被自动配置时，开启debug=true日志，或者访问Actuator的/conditions端点。它会生成一份详细的“自动配置评估报告”，告诉你每个AutoConfiguration是因为哪个条件满足或不满足而被启用或跳过的。
2. 可靠性——精准排除：当某个自动配置与你的代码或另一个库冲突时，不要犹豫，立即禁用它。使用@SpringBootApplication(exclude = {DataSourceAutoConfiguration.class})可以精准地“拔掉”某个自动配置，让你完全接管。
3. 可维护性——优先自定义：自动配置是起点，不是终点。对于核心组件，如数据源、线程池、消息队列客户端，强烈建议显式地使用@Bean方法自定义它们。这不仅能让你精细控制参数，也让配置意图一目了然，代码更易维护。

Spring Boot的本质，不是颠覆Spring，而是成为Spring的最佳实践布道者

• 永远不要把Spring Boot的“自动”当作“全自动”，理解其背后的条件是驾驭它的前提。
• 遇到“灵异事件”，第一反应应该是去查Actuator的/conditions端点。
• starter依赖是“全家桶”，用mvn dependency:tree看清楚它到底给你带了什么。
• 需要微调自动配置时，优先使用application.properties，而不是直接exclude。
• 自定义的@Bean会覆盖自动配置的Bean，这是规则，也是最佳实践。
• spring.factories和.imports文件是所有starter的“户口本”，想知道一个starter做了什么，先从这里看起。
• 内嵌服务器虽好，但生产环境的线程数、最大连接数等核心参数必须手动配置。