关键在于用-verbose:class日志、debug=true报告和mvn dependency:tree三层联动定位无效三方包：先抓加载但未激活的异常模式，再以自动配置报告终审是否真被使用，最后用依赖树精准溯源并exclusions裁剪。
面试中讲清楚类加载日志追踪定位无效三方包，关键不是堆参数，而是展现你如何用日志线索串联起“加载行为—Spring激活状态—依赖源头”三层判断逻辑。下面分三块说清怎么答得有条理、有细节、不空泛。
一、用-verbose:class抓“加载了但没用上”的信号
启动时加-verbose:class，重点不是看类有没有被加载，而是盯三类异常模式：
- 同一 jar（比如 guava-31.1-jre.jar）在启动前半段密集刷屏加载几十个类，但 debug=true 报告里完全没出现
GuavaAutoConfiguration或任何关联 Positive match ——说明它只是被 classpath 拖进来的“背景板”； - 多个版本同名库共存（如 okhttp-3.14.9.jar 和 okhttp-4.12.0.jar），但日志里只看到 4.12.0 的类被加载，3.14.9 完全静默 ——后者大概率是传递依赖引入的冗余包；
- 某个 jar 的类集中加载后，后续再无任何
@Component、@Configuration或自动配置类被触发（比如没看到NettyReactiveWebServerFactory相关加载）——基本可判定它未参与实际功能构建。
二、用 debug=true 报告做“是否真被用”的终审依据
debug=true 输出的自动配置报告才是黄金标准。回答时可强调你如何交叉验证：
- 在 Negative matches 里看到
RedisAutoConfiguration因@ConditionalOnClass不满足被跳过，立刻回头查 -verbose:class 日志 ——如果连RedisConnectionFactory这种基础类都没加载过，那整个spring-boot-starter-data-redis就是空载； - 某 jar 所有类都加载了，但报告中既没 Positive match 也没 Negative match 相关项 ——说明 Spring 根本没扫描到它，也不是条件不满足，而是压根没把它纳入自动配置上下文；
- 对比 Positive matches 列表和 -verbose:class 中实际加载的类来源，能快速反向锁定哪个 starter 激活了哪些底层 jar。
三、用 mvn dependency:tree 定位并裁剪冗余源头
确认无效后，不直接删，而是用 Maven 工具找“谁带进来的”：
- 运行
mvn dependency:tree -Dincludes=groupId:artifactId（比如-Dincludes=com.google.guava:guava），看它从哪条路径透传进来； - 常见情况是某个老版本 starter（如
spring-cloud-starter-netflix-eureka-client）拉入了旧版 guava，而新项目实际用的是 spring-boot 3.x 自带的更高版本； - 裁剪时优先用
<exclusions></exclusions>排除传递依赖，而不是全局 exclude ——避免误伤其他模块真正需要的版本。
面试时说完这三点，可以补一句：“我习惯把 -verbose:class 日志重定向到文件，配合 grep 和 wc -l 快速统计各 jar 加载类数，再和 debug 报告人工对齐 ——不依赖工具，逻辑闭环才扎实。”
