已有@Conditional与@Configuration时为何还需@EnableAutoConfiguration

@Configuration + @Conditional 本身完全不具备跨jar包扫描、加载第三方依赖配置的能力，@EnableAutoConfiguration是Spring Boot自动配置体系的入口，三者的职责完全不重叠，不存在谁替代谁的说法。

具体差异拆解 #

• 普通@Configuration的生效范围有严格边界
  我们平时写的加了@Configuration的配置类，哪怕全量加上@Conditional系列注解，也必须被@ComponentScan扫描到才能被Spring解析。而默认的组件扫描只会覆盖启动类所在包及其子路径，你引入的第三方starter依赖里的配置类，根本不在这个扫描范围内，你自己写的配置类逻辑根本碰不到这些jar里的内容。
• @Conditional只是判断规则，没有加载能力
  不管是@ConditionalOnClass还是@ConditionalOnMissingBean，本质都只是“满足条件才让当前标注的类/Bean生效”的判断逻辑，它本身不会主动去类路径下找哪些类需要被判断、哪些配置需要被加载，相当于它只是个门卫，根本不会主动出门找人进来。
• @EnableAutoConfiguration才是自动配置的“触发器”
  这个注解本身通过@Import导入了自动配置相关的处理器，会在启动时遍历所有依赖jar包的固定配置位：
  • Spring Boot 2.x 读取META-INF/spring.factories中配置的自动配置类
  • Spring Boot 3.x 读取META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports中配置的自动配置类
    这些预先定义在starter里的自动配置类，本身已经加好了全套@Conditional判断逻辑：比如类路径存在DispatcherServlet才加载SpringMVC相关配置、容器里没有自定义的TomcatServletWebServerFactory才用默认的内嵌Tomcat配置，满足条件才会把对应的Bean注册到容器里。

举个最直白的例子 #

如果你新建个Spring Boot项目，只写@Configuration + @ComponentScan，把@EnableAutoConfiguration去掉，哪怕你pom里引入了全套web starter依赖，启动的时候根本不会初始化内嵌Tomcat、不会注册DispatcherServlet，因为Spring根本不知道这些依赖里还带了配置类，完全不会去加载。你要是想跑起来Web服务，就得自己手动把starter里几十个配置类全用@Import一个个导进来，这就完全失去了Spring Boot“约定大于配置”的核心优势。

补充一句：我们平时用的@SpringBootApplication是个组合注解，里面已经包含了@Configuration、@ComponentScan、@EnableAutoConfiguration三个注解，所以很多时候你感知不到单独加@EnableAutoConfiguration的动作，但不代表它的能力可以被另外两个注解替代。

内容的提问来源于stack exchange，提问作者ghostrider