直接用-verbose:class参数可识别“白忙活”的三方包：大量同类JAR类密集加载但自动配置报告无匹配，或多个版本同名库仅一方被使用，结合debug=true报告和mvn dependency:tree可精准定位并裁剪冗余依赖。
直接用 -verbose:class 参数就能看到每个类从哪个 JAR、由哪个类加载器加载，再结合启动日志里的耗时分布，一眼识别出哪些三方包在“白忙活”——它们被加载了，但后续根本没被 Spring 扫描或实例化。
看懂 -verbose:class 输出的关键线索
启动时加上该 JVM 参数后，控制台会逐行打印类似：
[Loaded org.springframework.boot.autoconfigure.web.servlet.WebMvcAutoConfiguration from file:/BOOT-INF/lib/spring-boot-autoconfigure-3.2.5.jar]
[Loaded com.google.common.base.Preconditions from file:/BOOT-INF/lib/guava-31.1-jre.jar]
[Loaded io.netty.buffer.PooledByteBufAllocator from file:/BOOT-INF/lib/netty-buffer-4.1.100.Final.jar]
重点不是“有没有加载”，而是关注三类信号：
- 大量来自同一 jar（如
guava-*.jar、netty-*.jar）的类密集出现，但后续自动配置报告（debug=true输出）里完全没提它——说明这个包只是被动加载，未参与任何 Bean 构建或条件判断； - 某个 jar 的类集中在启动前半段刷屏式加载，但之后再无关联 Bean 或配置类被触发（比如没看到
xxxAutoConfiguration或@Component类加载）； - 多个版本的同名库并存（如
okhttp-3.14.9.jar和okhttp-4.12.0.jar），但只有一方的类被实际使用，另一方纯属冗余占用内存和 I/O。
结合 debug=true 锁定“假活跃”依赖
debug=true 在 application.properties 中启用后，Spring Boot 会在启动末尾输出完整的自动配置报告。这份报告才是真正反映“哪些依赖被用上了”的依据：
- 在 Positive matches 里出现的 auto-configuration 类，说明对应 starter 或 jar 的功能已激活；
- 在 Negative matches 里看到某配置项因
@ConditionalOnClass不满足而跳过，再回头查-verbose:class日志——如果连它的基础类（如RedisConnectionFactory）都没加载过，那整个spring-boot-starter-data-redis就是空载； - 如果某 jar 的所有类都加载了，但报告中既没匹配也没拒绝任何相关配置，基本可判定：它只是被 classpath 拖进来的“背景板”。
用 mvn dependency:tree 定位源头并裁剪
确认某个包无效后，别急着删，先查它是谁带进来的：
- 运行
mvn dependency:tree -Dincludes=groupId:artifactId（例如-Dincludes=com.squareup.okhttp3:okhttp），快速定位引入路径； - 若发现是某个 starter 的传递依赖（如
spring-cloud-starter-openfeign带入了整套okhttp，但项目实际用的是HttpClient），就在该 starter 下加<exclusion>排除； - 对明确不用的模块（如
spring-boot-starter-thymeleaf却没写任何模板），直接从 pom 中移除，避免它触发额外的资源扫描与 EL 表达式解析器加载。
观察类加载阶段耗时佐证判断
根据实测数据，类加载阶段占 Spring Boot 启动总耗时超 50%。如果某个三方包贡献了大量 [Loaded xxx] 日志，却没带来任何 BeanDefinition 注册或 @Configuration 处理，它就是在拖慢启动：
- 对比不同环境（如本地 vs 测试服）的
-verbose:class输出行数，若某环境多出上万行来自org.apache.logging.log4j的类加载，而日志框架实际只用 SLF4J 绑定，说明 Log4j2 被误加载； - 注意那些只加载接口、抽象类、测试工具类（如
org.junit.jupiter.api.Test）的 jar——它们本不该出现在生产 classpath 中，属于构建配置疏漏。
