springboot自动配置排除失效需从源头切断：确认类是否在autoconfiguration.imports中，非官方类须用excludename或配置文件；检查多处@enableautoconfiguration重复启用；通过-ddebug=true验证排除是否生效；终极方案包括yml排除、删除spring.factories条目及清理传递依赖。
SpringBoot自动配置排除某个类后仍然生效，说明排除操作未命中目标类或被其他路径重新引入，必须从加载源头切断其参与装配的全部可能路径。
确认被排除的类名是否准确
打开 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports 文件（位于 spring-boot-autoconfigure.jar 内），搜索你要排除的类全限定名，例如 DataSourceAutoConfiguration。如果该类不在这个文件里，说明它根本不是 Spring Boot 官方自动配置类，而是第三方 starter 或自定义 starter 提供的，此时用 @SpringBootApplication(exclude = ...) 无效——【exclude 只对 spring.factories 或 AutoConfiguration.imports 中声明的自动配置类生效】。
若查到的是 com.example.starter.MyAutoConfig 这类非官方类，必须改用 excludeName 或配置文件方式排除，且类名字符串必须一字不差。
检查是否存在多处@EnableAutoConfiguration重复启用
全局搜索项目中所有 @EnableAutoConfiguration 注解，尤其注意自定义 starter 的配置类、测试类、或模块化子工程中的启动配置。只要有一处没加 exclude，该自动配置就可能被重新加载。
Spring Boot 只认第一个 @EnableAutoConfiguration 的 exclude 参数，后续同注解会覆盖前一个——【重复声明 @EnableAutoConfiguration 会导致排除失效】。
验证排除是否发生在正确阶段
第一步：在启动类上添加 JVM 参数 -Ddebug=true，运行应用。
一款AI工具，主要用于使用 CodexBar CLI 本地成本使用情况，按模型汇总 Codex 或 Claude 的使用量，包括当前（最新）模型或完整的模型分解，适合需要提升相关任务效率的用户。
第二步：观察控制台输出的 “Exclusions:” 列表，确认你要排除的类名是否出现在其中。如果没有，说明注解参数未被识别或拼写错误。
第三步：再查看 “Auto-configuration report” 部分，搜索该类名。如果显示 “Excluded by: …”，说明已成功排除；如果显示 “Not matched” 或 “Matched”，说明条件判断通过了，它仍参与了装配流程——此时问题不在 exclude，而在其内部 @ConditionalOn… 注解未被触发跳过，需检查类路径依赖或已有 Bean 是否满足条件。
终极强制剔除方案
方法一：在 application.yml 中写死排除项，绕过编译期校验和注解解析歧义：
spring: autoconfigure: exclude: - org.springframework.boot.autoconfigure.jdbc.DataSourceAutoConfiguration
方法二：若目标类来自第三方 starter（如某国产数据库 starter），且其未按 Spring Boot 规范注册在 AutoConfiguration.imports 中，而是在 META-INF/spring.factories 里声明的，则必须同时清除两种注册源：
① 在启动类加 @SpringBootApplication(excludeName = "com.vendor.db.VendorAutoConfiguration")；
② 在 src/main/resources/META-INF/spring.factories 中手动删除对应行（若存在）；
③ 确保该 starter 的 JAR 包未被其他模块间接传递依赖引入——用 mvn dependency:tree -Dincludes=com.vendor 检查。
