🔍 Maven dependency:tree 的 8 个高级用法

💡 摘要: 本文深入讲解 Maven dependency:tree 命令的 8 个高级用法，涵盖依赖冲突排查、传递依赖分析、版本升级建议等实战场景。通过企业级真实案例，展示如何利用这个强大工具快速定位和解决复杂的依赖问题。提供可视化分析方法、自动化脚本工具和企业级依赖管理规范，让你掌握专业级的依赖分析技能。

🎯 前言：为什么你需要掌握 dependency:tree？

1.1 依赖冲突那些痛

真实案例一：诡异的 ClassCastException
现象：运行时抛出 ClassCastException
错误信息：com.google.common.collect.ImmutableList cannot be cast to ...
排查过程:

- 检查代码，类型转换没问题
- 查看依赖，发现 Guava 有两个版本
- A 依赖引入 Guava 20.0
- B 依赖引入 Guava 31.1-jre
- Maven 选择了 20.0（较近的）
- 但代码是按 31.1 的特性写的
  结果：类型转换失败

解决：排除旧版本，强制使用新版本

如果早点掌握 dependency:tree，这个问题 5 分钟就能解决！

真实案例二：jar Hell 地狱
项目启动报错：
NoSuchMethodError: XXX.method()

排查发现:

- spring-core 有 4 个不同版本
- spring-beans 有 3 个不同版本
- 总共 50+ 个 Spring 相关 jar
- 各种版本交叉依赖

就像一锅粥，谁也说不清谁依赖谁

用 dependency:tree 一看，一目了然！

1.2 dependency:tree 能帮你什么

🌟 用法一：基础查看依赖树 ⭐⭐⭐⭐⭐

2.1 基本命令

# 查看当前项目的完整依赖树
mvn dependency:tree

# 输出示例
[INFO] --- maven-dependency-plugin:3.5.0:tree (default-cli) @ my-project ---
[INFO] com.example:my-project:jar:1.0.0
[INFO] +- org.springframework.boot:spring-boot-starter:jar:3.2.0:compile
[INFO] |  +- org.springframework.boot:spring-boot:jar:3.2.0:compile
[INFO] |  +- org.springframework.boot:spring-boot-autoconfigure:jar:3.2.0:compile
[INFO] |  +- org.springframework:spring-core:jar:6.1.1:compile
[INFO] |  \- org.springframework:spring-context:jar:6.1.1:compile
[INFO] +- com.google.guava:guava:jar:31.1-jre:compile
[INFO] \- junit:junit:jar:4.13.2:test

2.2 读懂依赖树符号

符号说明:
+- 直接依赖（第一层）
| +- 传递依赖（第二层）
| | +- 传递依赖（第三层）
\- 最后一个直接依赖
\- 它的传递依赖

Scope 标识:
compile: 编译和运行时都需要
provided: 仅需编译，运行时由容器提供
runtime: 仅运行时需要
test: 仅测试时需要
system: 系统提供的本地 jar

2.3 输出到文件

# 输出到文本文件
mvn dependency:tree -DoutputFile=deps.txt

# 查看文件
cat deps.txt

# 或用编辑器打开
code deps.txt  # VS Code
notepad deps.txt  # Windows

🔍 用法二：包含过滤（includes）⭐⭐⭐⭐⭐

3.1 查找特定依赖

# 查找所有包含"spring"的依赖
mvn dependency:tree -Dincludes=org.springframework:*

# 输出
[INFO] +- org.springframework.boot:spring-boot-starter:jar:3.2.0:compile
[INFO] |  +- org.springframework.boot:spring-boot:jar:3.2.0:compile
[INFO] |  +- org.springframework:spring-core:jar:6.1.1:compile

3.2 精确匹配

# 查找特定的 artifact
mvn dependency:tree -Dincludes=com.google.guava:guava

# 查找特定版本
mvn dependency:tree -Dincludes=junit:junit:4.13.2

3.3 通配符匹配

# 使用通配符
mvn dependency:tree -Dincludes="*:spring-*"

# 查找所有 spring 开头的依赖
mvn dependency:tree -Dincludes="org.springframework:**"

3.4 实战场景

场景一：想知道哪里引入了某个依赖
问题：项目中出现了 slf4j，但我不记得在哪里引入的

解决:
mvn dependency:tree -Dincludes=org.slf4j:*

输出会显示完整的引入路径:
A → B → C → slf4j
这样就知道是哪个依赖带来的了

🚫 用法三：排除过滤（excludes）⭐⭐⭐⭐

4.1 排除特定依赖

# 查看依赖树，但不包含某些依赖
mvn dependency:tree -Dexcludes=org.slf4j:slf4j-simple

# 排除多个依赖
mvn dependency:tree \
  -Dexcludes=org.slf4j:slf4j-simple,junit:junit

4.2 实战应用

场景：怀疑某个依赖有问题，想临时排除它测试

步骤:

1. 先用 excludes 排除该依赖
   mvn dependency:tree -Dexcludes=com.xxx:problem-lib

2. 运行测试
   mvn test

3. 如果问题解决，说明确实是该依赖的问题
4. 在 pom.xml 中正式排除或升级

📊 用法四：详细模式（verbose）⭐⭐⭐⭐⭐

5.1 启用详细模式

# 显示被省略的版本
mvn dependency:tree -Dverbose

# 输出示例
[INFO] +- org.springframework:spring-core:jar:6.1.1:compile
[INFO] |  \- (org.springframework:spring-jcl:jar:6.1.1:compile - omitted for duplicate)

5.2 理解"omitted"

常见省略原因:
omitted for duplicate:
重复的依赖，Maven 选择了其中一个

omitted for conflict with version X.X:
版本冲突，Maven 选择了另一个版本

omitted as scope 'test' is closer than 'compile':
scope 冲突，选择了更近的 scope

5.3 实战价值

通过 verbose 模式，你可以:

1. 发现隐藏的依赖冲突
2. 理解 Maven 的仲裁机制
3. 找到被意外覆盖的版本
4. 优化依赖结构

这是排查复杂依赖问题的利器！

🎯 用法五：指定模块（pl）⭐⭐⭐⭐

6.1 单模块分析

# 只看某个模块的依赖树
mvn dependency:tree -pl user-service

# 多模块项目非常有用
# 避免输出太长看不清

6.2 连带依赖一起看

# 包含依赖该模块的其他模块
mvn dependency:tree -pl user-service -am

# -am = --also-make
# 同时显示父模块和依赖的模块

6.3 组合使用

# 查看特定模块中包含 spring 的依赖
mvn dependency:tree -pl order-service \
  -Dincludes=org.springframework:* \
  -Dverbose

📈 用法六：生成可视化图表 ⭐⭐⭐

7.1 生成 DOT 格式

# 安装 graphviz（用于渲染 DOT 文件）
# Mac
brew install graphviz

# Ubuntu
sudo apt-get install graphviz

# 生成 DOT 文件
mvn dependency:tree -DoutputType=dot -DoutputFile=deps.dot

# 转换为图片
dot -Tpng deps.dot -o deps.png

# 打开查看
open deps.png  # Mac
xdg-open deps.png  # Linux
start deps.png  # Windows

7.2 在线可视化工具

推荐工具:

1. Gource: https://gource.io/
   动态展示项目演化

2. Deps.dev: https://deps.dev/
   Google 提供的依赖分析工具

3. Snyk: https://snyk.io/
   安全漏洞扫描 + 依赖分析

🔬 用法七：深度控制（depth）⭐⭐⭐

8.1 限制显示深度

# 只显示前 2 层
mvn dependency:tree -Ddepth=2

# 只显示直接依赖
mvn dependency:tree -Ddepth=1

# 显示完整深度（默认）
mvn dependency:tree -Ddepth=999

8.2 适用场景

深度=1:
只想看直接引入了哪些库

深度=2:
想看直接依赖 + 它们的主要依赖

深度=3+:
深入分析传递依赖
排查复杂的依赖冲突

💡 用法八：结合其他命令 ⭐⭐⭐⭐

9.1 与 analyze 结合

# 分析未使用的依赖
mvn dependency:analyze

# 先分析，再看树状结构
mvn dependency:tree -Dincludes=未使用的依赖

9.2 与 purge 结合

# 清理本地仓库后重新分析
mvn dependency:purge-local-repository
mvn dependency:tree -Dverbose

9.3 与 resolve 结合

# 解析并下载所有依赖
mvn dependency:resolve
mvn dependency:tree

🏢 企业级实战案例

案例一：Spring 版本冲突排查

问题背景:
项目启动时报错:
Caused by: java.lang.ClassNotFoundException:
org.springframework.util.StringUtils

排查过程:

步骤 1: 查看完整依赖树
mvn dependency:tree -Dverbose > tree.txt

步骤 2: 搜索 Spring 相关
grep "spring-core" tree.txt

发现:

- spring-boot-starter 引入 spring-core 6.1.1
- 第三方库引入 spring-core 5.3.20

步骤 3: 找出是谁引入的旧版本
mvn dependency:tree -Dincludes=org.springframework:spring-core -Dverbose

输出:
[INFO] +- com.thirdparty:old-lib:jar:1.0.0:compile
[INFO] | \- (org.springframework:spring-core:jar:5.3.20:compile - omitted for conflict with 6.1.1)

步骤 4: 解决方案
方案 A: 升级 old-lib 到支持 Spring 6 的版本
方案 B: 强制指定 Spring 版本
方案 C: 排除旧版本，显式引入新版本

最终选择方案 B:
<dependencyManagement>
<dependencies>
<dependency>
<groupId>org.springframework</groupId>
<artifactId>spring-core</artifactId>
<version>6.1.1</version>
</dependency>
</dependencies>
</dependencyManagement>

案例二：日志框架冲突解决

问题:
日志不输出，控制台一片空白

排查:
mvn dependency:tree -Dincludes=org.slf4j:* -Dverbose

发现:

- slf4j-api 1.7.36
- slf4j-simple 1.7.36
- logback-classic 1.4.11 (依赖 slf4j-api 2.0.x)
- log4j-slf4j-impl 2.20.0 (也依赖 slf4j-api)

问题根源:
SLF4J 有多个实现，互相冲突

解决:
统一使用 logback:

1. 排除其他实现
2. 只保留 logback

<dependencies>
  <!-- 排除 log4j -->
  <dependency>
    <groupId>xxx</groupId>
    <artifactId>xxx</artifactId>
    <exclusions>
      <exclusion>
        <groupId>org.apache.logging.log4j</groupId>
        <artifactId>*</artifactId>
      </exclusion>
    </exclusions>
  </dependency>

  <!-- 统一使用 logback -->
  <dependency>
    <groupId>ch.qos.logback</groupId>
    <artifactId>logback-classic</artifactId>
    <version>1.4.11</version>
  </dependency>
</dependencies>

🛠️ 自动化脚本

依赖分析报告生成器

#!/bin/bash
# dependency-report.sh

echo "📊 开始生成 Maven 依赖分析报告..."

PROJECT_NAME=$(basename $(pwd))
REPORT_DIR="dependency-report"
mkdir -p $REPORT_DIR

# 1. 完整依赖树
echo "1. 生成完整依赖树..."
mvn dependency:tree -DoutputFile=$REPORT_DIR/full-tree.txt

# 2. 详细模式
echo "2. 生成详细依赖树..."
mvn dependency:tree -Dverbose -DoutputFile=$REPORT_DIR/verbose-tree.txt

# 3. 按 groupId 分类
echo "3. 按组织分类统计..."
for group in org.springframework org.apache.commons com.google; do
    mvn dependency:tree -Dincludes=$group:\* \
      -DoutputFile=$REPORT_DIR/${group}.txt 2>/dev/null
done

# 4. 依赖统计
echo "4. 统计依赖数量..."
mvn dependency:count-plugins \
  -DoutputFile=$REPORT_DIR/plugin-count.txt

# 5. 生成 HTML 报告（如果有依赖插件）
echo "5. 生成 HTML 报告..."
mvn dependency:tree -DoutputType=dot \
  -DoutputFile=$REPORT_DIR/tree.dot

if command -v dot &> /dev/null; then
    dot -Thtml $REPORT_DIR/tree.dot \
      -o $REPORT_DIR/tree.html
fi

echo ""
echo "✅ 报告生成完成!"
echo "报告目录：$(pwd)/$REPORT_DIR"
echo ""
echo "查看报告:"
echo "  cat $REPORT_DIR/full-tree.txt"
echo "  open $REPORT_DIR/tree.html"

📊 依赖健康检查清单

✅ 检查项:

1. 版本一致性
   □ 同一库没有多个版本
   □ Spring 系列版本匹配
   □ Log4j/SLF4J 版本统一

2. 依赖必要性
   □ 没有未使用的依赖
   □ 测试依赖 scope 正确
   □ 没有循环依赖

3. 安全性
   □ 无已知安全漏洞
   □ 版本不是太老
   □ 定期更新依赖

4. 性能优化
   □ 没有过大的依赖
   □ 传递依赖合理
   □ 构建时间可接受

🎁 福利：常用命令速查表

# 基础命令
mvn dependency:tree                              # 查看完整依赖树
mvn dependency:tree -DoutputFile=deps.txt       # 输出到文件

# 过滤命令
mvn dependency:tree -Dincludes=groupId:artifactId  # 包含过滤
mvn dependency:tree -Dexcludes=groupId:artifactId  # 排除过滤
mvn dependency:tree -Dverbose                      # 详细模式

# 模块控制
mvn dependency:tree -pl module-name               # 指定模块
mvn dependency:tree -pl module -am                # 包含依赖

# 深度控制
mvn dependency:tree -Ddepth=1                     # 只看直接依赖
mvn dependency:tree -Ddepth=2                     # 看前两层

# 高级组合
mvn dependency:tree -pl xxx -Dincludes=yyy -Dverbose

🕳️ 避坑指南：依赖树分析的 6 个致命错误

⚠️ 错误 1：只看直接依赖，不管传递依赖

现象：pom.xml 看起来很干净，但项目问题不断

实际情况：

❌ 错误认知：
我的 pom.xml 只有 10 个直接依赖，很简洁！

✅ 残酷现实：
mvn dependency:tree 一看
├─ 直接依赖：10 个
└─ 传递依赖：150+ 个
    ├─ Spring 相关：30 个
    ├─ Jackson 相关：20 个
    └─ 其他传递依赖：100+ 个

问题：
- 传递依赖版本冲突
- 重复的类定义
- 不必要的依赖引入
- 安全隐患传递

案例分析：

<!-- 你的 pom.xml -->
<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-web</artifactId>
  </dependency>

  <dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
  </dependency>
</dependencies>

  <!-- 看起来很简单？实际上传递依赖很复杂 -->
  <!-- 运行以下命令查看真相 -->
  mvn dependency:tree -Dverbose

✅ 正确做法：

# 每次修改依赖后都检查完整树
mvn dependency:tree

# 特别关注传递依赖
mvn dependency:tree -Dincludes=*

# 分析是否有冲突
mvn dependency:analyze

# 识别未使用的依赖
mvn dependency:analyze-unused

最佳实践：

• ✅ 定期（每周）检查依赖树
• ✅ 重点关注传递依赖的版本
• ✅ 使用 BOM 统一管理框架依赖
• ✅ 排除不必要的传递依赖

⚠️ 错误 2：忽视 Maven 的"就近原则"

现象：明明指定了版本，但运行时不是这个版本

风险等级: 🔴 高危

Maven 仲裁规则：

路径最短优先（就近原则）:

项目 → A 依赖 → commons-lang3:2.7
项目 → B 依赖 → C 依赖 → commons-lang3:3.12

结果：Maven 选择 2.7 版本（路径更短）
即使 3.12 版本更新！

声明优先原则:

如果路径长度相同
先声明的依赖获胜

<dependencies>
  <dependency>A</dependency>  <!-- 先声明，获胜 -->
  <dependency>B</dependency>
</dependencies>

真实案例：

<!-- ❌ 问题配置 -->
<dependencies>
  <!-- 引入旧版 Guava -->
  <dependency>
    <groupId>com.example</groupId>
    <artifactId>library-a</artifactId>
    <version>1.0.0</version>
    <!-- 传递依赖：guava 20.0 -->
  </dependency>

  <!-- 想引入新版 Guava -->
  <dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <version>31.1-jre</version>
  </dependency>
</dependencies>

  <!-- 结果：由于 library-a 先声明，Guava 20.0 获胜 -->

✅ 解决方案：

方案 A：使用 dependencyManagement 强制管理

<dependencyManagement>
  <dependencies>
    <dependency>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
      <version>31.1-jre</version>  <!-- 强制使用此版本 -->
    </dependency>
  </dependencies>
</dependencyManagement>

<dependencies>
<!-- 这里不需要写 version -->
<dependency>
  <groupId>com.google.guava</groupId>
  <artifactId>guava</artifactId>
</dependency>
</dependencies>

方案 B：排除传递依赖

<dependency>
  <groupId>com.example</groupId>
  <artifactId>library-a</artifactId>
  <exclusions>
    <exclusion>
      <groupId>com.google.guava</groupId>
      <artifactId>guava</artifactId>
    </exclusion>
  </exclusions>
</dependency>

  <!-- 单独引入新版本 -->
<dependency>
<groupId>com.google.guava</groupId>
<artifactId>guava</artifactId>
<version>31.1-jre</version>
</dependency>

⚠️ 错误 3：滥用 optional 依赖

现象：为了减少传递依赖，把所有依赖都设为 optional

风险等级: 🟡 中危

错误示范：

<!-- ❌ 过度使用 optional -->
<dependencies>
  <dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter</artifactId>
    <optional>true</optional>  <!-- 不该用 -->
  </dependency>

  <dependency>
    <groupId>com.google.guava</groupId>
    <artifactId>guava</artifactId>
    <optional>true</optional>  <!-- 不该用 -->
  </dependency>

  <!-- 所有依赖都 optional... -->
</dependencies>

  结果：
  - 子模块无法继承依赖
  - 运行时 ClassNotFound
  - 打包后缺少必要 jar

optional 的正确理解：

optional=true 的含义:

✅ 适用场景:
- 可选功能依赖（如插件系统）
- 测试工具依赖
- 特定场景才需要的依赖

❌ 不适用场景:
- 核心业务依赖
- 运行时必需的依赖
- 框架基础依赖

传递规则:
A (optional) → B
↓
C 依赖 A
↓
C 不会自动获得 B

需要 C 显式声明依赖 B

✅ 正确使用示例：

<!-- ✅ 核心依赖（不设置 optional） -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter</artifactId>
</dependency>

  <!-- ✅ 可选功能依赖（设置 optional） -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-configuration-processor</artifactId>
<optional>true</optional>
</dependency>

  <!-- ✅ 测试依赖（使用 test scope） -->
<dependency>
<groupId>junit</groupId>
<artifactId>junit</artifactId>
<scope>test</scope>
</dependency>

⚠️ 错误 4：不看依赖的 scope

现象：编译通过，运行时失败

典型场景：

场景一：provided 依赖误用
<dependency>
  <groupId>javax.servlet</groupId>
  <artifactId>javax.servlet-api</artifactId>
  <scope>provided</scope>  <!-- 仅编译时需要 -->
</dependency>

问题：
- 本地开发（Tomcat 提供 servlet API）✅ 正常
- 打成 fat jar 独立运行 ❌ 失败
- 原因：provided 依赖不会打包

场景二：test 依赖误用
<dependency>
  <groupId>junit</groupId>
  <artifactId>junit</artifactId>
  <scope>test</scope>  <!-- 仅测试时需要 -->
</dependency>

问题：
- 在 main 代码中引用了测试类
- 编译报错：找不到符号
- 因为 junit 只在测试 classpath

Scope 详解：

记忆口诀:
compile 全都要
provided 容器给
test 只测不用跑
runtime 跑时才要

✅ 最佳实践：

<!-- ✅ 默认使用 compile（不写就是 compile） -->
<dependency>
  <groupId>org.springframework.boot</groupId>
  <artifactId>spring-boot-starter</artifactId>
  <!-- scope 默认为 compile -->
</dependency>

  <!-- ✅ Tomcat 等容器提供的依赖 -->
<dependency>
<groupId>javax.servlet</groupId>
<artifactId>javax.servlet-api</artifactId>
<scope>provided</scope>
</dependency>

  <!-- ✅ 数据库驱动（运行时才需要） -->
<dependency>
<groupId>mysql</groupId>
<artifactId>mysql-connector-java</artifactId>
<scope>runtime</scope>
</dependency>

  <!-- ✅ 测试框架 -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-test</artifactId>
<scope>test</scope>
</dependency>

⚠️ 错误 5：依赖树输出太多就不管

现象：依赖树太长（500+ 行），直接放弃分析

实际问题：

大型项目依赖树:
mvn dependency:tree > deps.txt
wc -l deps.txt
结果：800+ 行！

开发者反应：😱 太多了，不看！

后果:
- 隐藏的版本冲突
- 冗余依赖浪费空间
- 安全风险传递
- 构建时间增加

✅ 高效分析方法：

方法一：分层过滤

# 第一步：只看直接依赖
mvn dependency:tree -Ddepth=0
# 输出：只显示第一层依赖（通常 20-30 个）

# 第二步：查看有问题的特定依赖
mvn dependency:tree -Dincludes=com.google.guava

# 第三步：深度分析特定模块
mvn dependency:tree -pl :problem-module -Dverbose

方法二：可视化工具

# 生成 DOT 文件（Graphviz 格式）
mvn dependency:tree -DoutputFile=deps.dot

# 转换为 PNG 图片（需要安装 Graphviz）
dot -Tpng deps.dot -o deps.png

# 或用在线工具查看
# https://dreampuf.github.io/GraphvizOnline/

方法三：IDEA 插件

推荐插件:

1. Maven Helper (⭐⭐⭐⭐⭐)

- 可视化依赖树
- 快速搜索依赖
- 一键解决冲突

2. Dependency Analyzer

- 图形化展示
- 识别循环依赖
- 统计依赖大小

使用技巧:

- 右键 pom.xml → Open Dependency Visualization
- Ctrl+F 搜索特定依赖
- 红色标记表示冲突

方法四：自动化脚本

#!/bin/bash
# check-dependencies.sh

echo "=== 依赖统计 ==="
mvn dependency:tree | grep -c "^\[INFO\]" | xargs echo "总行数:"

echo -e "\n=== 直接依赖 ==="
mvn dependency:tree -Ddepth=0 | grep "^\[INFO\] +-" | wc -l | xargs echo "数量:"

echo -e "\n=== 检查冲突 ==="
mvn dependency:analyze | grep -E "(CONFLICT|WARNING)" | head -20

echo -e "\n=== 未使用依赖 ==="
mvn dependency:analyze-unused | grep "Unused declared dependencies" -A 10

⚠️ 错误 6：不建立依赖审查机制

现象：随便引入依赖，不考虑后果

团队协作灾难：

真实案例：

开发 A：引入一个新库（没告诉团队）
开发 B：又引入类似的库（功能重复）
开发 C：发现冲突，手动排除
开发 D：不知道为什么要排除，跟着改

半年后:
- pom.xml 面目全非
- 各种奇怪的 exclusion
- 没人知道为什么这样配
- 构建时间从 5 分钟变 20 分钟

✅ 建立依赖审查流程：

流程一：引入新依赖前检查清单

□ 必要性评估

- 是否真的需要这个依赖？
- 能否用现有依赖实现？
- 是否值得为此增加复杂度？

□ 质量评估

- GitHub Star 数 > 100?
- 最后更新时间 < 6 个月？
- 下载量 > 10000/月？
- 有无重大安全漏洞？

□ 兼容性评估

- 与现有依赖版本兼容吗？
- 会引入冲突吗？
- 需要排除传递依赖吗？

□ 许可证检查

- 开源协议是什么？
- 能商用吗？
- 需要公开源码吗？

流程二：PR/MR 审查要点

Code Review 检查清单:

✅ pom.xml 变更
□ 新增依赖是否必要？
□ 版本号是否明确？
□ 是否需要 exclusion？
□ scope 是否正确？

✅ 影响评估
□ 构建时间影响？
□ 包体积增加？
□ 是否有破坏性变更？
□ 需要更新文档吗？

✅ 验证步骤
□ mvn dependency:tree 检查
□ mvn dependency:analyze 分析
□ 本地构建测试
□ CI/CD流水线验证

流程三：定期依赖审计

# 每月执行一次依赖健康检查

# 1. 检查过期依赖
mvn versions:display-dependency-updates

# 2. 检查安全漏洞
mvn org.owasp:dependency-check-maven:check

# 3. 清理未使用依赖
mvn dependency:analyze-unused

# 4. 生成依赖报告
mvn dependency:resolve -Dclassifier=sbom

流程四：依赖管理规范

团队规范文档:

1. 版本管理

- 所有依赖必须明确版本号
- 使用 properties 统一管理
- 禁止使用 LATEST/RELEASE

2. 引入流程

- 提交依赖引入申请
- Tech Lead 审批
- 更新依赖清单文档

3. 维护责任

- 谁引入谁负责
- 定期更新版本
- 及时修复漏洞

4. 文档记录

- 维护依赖清单
- 记录引入原因
- 标注注意事项

💡 避坑总结

💬 互动环节

你在依赖管理中遇到过哪些奇葩问题？

欢迎在评论区分享你的排查经历和独门技巧!

常见问题 TOP5:

1. 依赖冲突导致 ClassCastException 怎么排查？
2. 如何快速找到传递依赖的来源？
3. dependency:tree 输出太多怎么看？
4. 如何排除不需要的传递依赖？
5. 多模块项目中依赖冲突如何处理？

💡 我会在评论区持续答疑，欢迎留言!