清理未使用的传递性依赖核心是“先看清、再判断、后动手”，需用mvn dependency:analyze识别Unused declared和Used undeclared依赖，结合mvn dependency:tree定位来源，人工验证反射/SPI等隐式使用场景，再通过注释→编译→运行→日志检查四步安全剔除。
清理未使用的传递性依赖，核心是“先看清、再判断、后动手”，不能靠直觉删，也不能全信工具结论。重点在于识别哪些传递依赖确实没被代码调用，又不会因反射、SPI、配置文件等隐式方式被使用。
用 mvn dependency:analyze 找出可疑依赖
这是最直接的起点。在项目根目录运行：
mvn dependency:analyze
输出中重点关注两部分：
- Unused declared dependencies：你在 pom.xml 里显式声明了，但编译期没被任何类引用——这类是最优先清理对象
- Used undeclared dependencies：代码里用了，但你没在 pom.xml 中声明（靠其他依赖间接带入）——这说明存在隐式依赖风险，建议补上声明，避免版本漂移
注意：该命令对反射调用（如 Class.forName）、Spring 的 @ComponentScan、MyBatis 的 XML 映射、Lombok 注解处理器等无法感知，结果需人工验证。
用 mvn dependency:tree 看清依赖来源
单看 analyze 不够，得知道某个 jar 是谁引来的。常用组合命令：
mvn dependency:tree -Dverbose -DoutputFile=tree.txt
-Dverbose 会标出被排除的冲突项（显示为 omitted for conflict），帮你发现隐藏的版本打架；-DoutputFile 把长列表导出，方便搜索。
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
例如想查 commons-lang3 是谁引入的：
mvn dependency:tree -Dincludes=org.apache.commons:commons-lang3
找到它的上游依赖后，再评估：如果只是某个已弃用模块引入的，且当前代码完全不用它，就可以考虑在那个上游依赖里
安全剔除的实操步骤
不要直接删 pom，按顺序操作更稳妥：
- 把疑似无用的 dependency 临时注释掉
- 执行 mvn clean compile，确认编译通过
- 启动应用，跑一遍核心业务流程（含接口调用、定时任务、消息消费等）
- 检查日志是否有
NoClassDefFoundError或ClassNotFoundException - 确认无误后再从 pom 中彻底删除
特别提醒：Spring Boot Starter 类型依赖（如 spring-boot-starter-data-redis）表面看没直接用，但可能支撑自动配置，删前务必查 autoconfigure 源码或启动日志里的 ConditionEvaluationReport。
预防冗余：从源头控制传递依赖
与其事后清理，不如提前约束：
- 优先选用功能聚焦的 starter（比如用
spring-boot-starter-webflux替代全量spring-boot-starter-web） - 对第三方 SDK，在其 dependency 块中主动
- 统一管理版本：用
不复杂但容易忽略
