spring.autoconfigure.exclude 配置项必须写在 application.properties 或 application.yml 中，用于启动早期全局排除自动配置类，会覆盖 @SpringBootApplication 的 exclude 参数。
spring.autoconfigure.exclude 配置项该写在哪儿
这个配置只在 application.properties 或 application.yml 里生效，不能写在 Java 类上、不能通过 @SpringBootApplication 的 exclude 参数动态传入（那是另一回事）。它属于 Spring Boot 启动早期的“全局排除”，影响所有自动配置类的加载判断。
- 写在
application.properties中：spring.autoconfigure.exclude=org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration - 写在
application.yml中：spring: autoconfigure: exclude: org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
- 多个类用逗号分隔（properties）或 YAML 列表形式（yml），注意不要漏掉完整类名，包路径必须精确
@SpringBootApplication 的 exclude 参数和 spring.autoconfigure.exclude 的区别
前者是编译期/启动时静态指定，后者是运行时配置驱动。两者不叠加，spring.autoconfigure.exclude 会覆盖 @SpringBootApplication(exclude = ...) 的效果 —— 只要配置项存在，它就优先生效。
-
@SpringBootApplication(exclude = DataSourceAutoConfiguration.class)：适合模块化项目中固定排除，IDE 可跳转、可被单元测试捕获 -
spring.autoconfigure.exclude=...：适合多环境差异化控制，比如测试环境关掉 Redis 自动配置，生产环境保留 - 混用时容易误以为“两个都写了就更保险”，实际是后者生效，前者被静默忽略
排除后为什么 Bean 还在？常见失效原因
自动配置类被排除，不代表它内部定义的所有 @Bean 都消失。如果其他配置类（比如你自己写的 @Configuration）也声明了同类型 Bean，或者有第三方 Starter 主动注册了同名 Bean，那最终容器里还是会有。
- 排除
DataSourceAutoConfiguration后，DataSourceBean 仍存在 → 很可能你手动配置了@Bean，或 MyBatis Starter 自带了基础数据源逻辑 - 排除
WebMvcAutoConfiguration后，@RestController还能响应请求 → 因为 Spring MVC 核心 Servlet 容器（如 Tomcat）和 DispatcherServlet 注册未被移除，只是默认 Web 配置没了 - 检查是否真的排除成功：启动日志搜
Excluding auto-configuration，或加--debug看 ConditionEvaluationReport
排除顺序和条件干扰问题
Spring Boot 的自动配置有依赖关系和条件判断（@ConditionalOnMissingBean、@ConditionalOnClass 等）。单纯排除一个类，可能让下游依赖它的配置类因条件不满足而“意外失效”，但你未必意识到。
- 排除
DataSourceAutoConfiguration，会导致JpaAutoConfiguration因找不到DataSource而跳过 —— 这是预期行为 - 但如果你只想要换掉数据源实现，又希望 JPA 继续工作，那就该保留
DataSourceAutoConfiguration，改用spring.datasource.type指定 Hikari 或 Druid，而不是粗暴排除 - 排除前先看类的
@AutoConfigureAfter/@AutoConfigureBefore注解，避免打断关键执行链
自动配置排除不是开关，而是对 Spring Boot 启动流程的一次“外科手术”。类与类之间的隐式依赖比表面看到的多得多，删错一个，后面一堆 Bean 就开始报 UnsatisfiedDependencyException，但错误堆栈里不会告诉你“因为你排除了 X”。
