Maven dependency:tree 的 8 個高級用法
更新時間：2026年06月22日 08:33:35 作者：行者全棧架構師
本文主要介紹了Maven dependency:tree 的 8 個高級用法,文中通過示例介紹的非常詳細,對大家的學習或者工作具有一定的參考學習價值,需要的朋友們下面隨著小編來一起學習學習吧
?? 摘要: 本文深入講解 Maven dependency:tree 命令的 8 個高級用法，涵蓋依賴沖突排查、傳遞依賴分析、版本升級建議等實戰(zhàn)場景。通過企業(yè)級真實案例，展示如何利用這個強大工具快速定位和解決復雜的依賴問題。提供可視化分析方法、自動化腳本工具和企業(yè)級依賴管理規(guī)范，讓你掌握專業(yè)級的依賴分析技能。
?? 前言：為什么你需要掌握 dependency:tree？
1.1 依賴沖突那些痛
真實案例一：詭異的 ClassCastException
現(xiàn)象：運行時拋出 ClassCastException
錯誤信息：com.google.common.collect.ImmutableList cannot be cast to ...
排查過程:
- 檢查代碼，類型轉換沒問題
- 查看依賴，發(fā)現(xiàn) Guava 有兩個版本
- A 依賴引入 Guava 20.0
- B 依賴引入 Guava 31.1-jre
- Maven 選擇了 20.0（較近的）
- 但代碼是按 31.1 的特性寫的
結果：類型轉換失敗
解決：排除舊版本，強制使用新版本
如果早點掌握 dependency:tree，這個問題 5 分鐘就能解決！
真實案例二：jar Hell 地獄
項目啟動報錯：
NoSuchMethodError: XXX.method()
排查發(fā)現(xiàn):
- spring-core 有 4 個不同版本
- spring-beans 有 3 個不同版本
- 總共 50+ 個 Spring 相關 jar
- 各種版本交叉依賴
就像一鍋粥，誰也說不清誰依賴誰
用 dependency:tree 一看，一目了然！
1.2 dependency:tree 能幫你什么
graph TB
A[dependency:tree] --> B[查看完整依賴樹]
A --> C[查找特定依賴]
A --> D[分析依賴沖突]
A --> E[識別冗余依賴]
A --> F[優(yōu)化依賴結構]
B --> G[了解項目全貌]
C --> H[快速定位問題]
D --> I[解決版本沖突]
E --> J[精簡依賴體積]
F --> K[提升構建性能]
?? 用法一：基礎查看依賴樹 ?????
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: 系統(tǒng)提供的本地 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 實戰(zhàn)場景
場景一：想知道哪里引入了某個依賴
問題：項目中出現(xiàn)了 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 實戰(zhàn)應用
場景：懷疑某個依賴有問題，想臨時排除它測試
步驟:
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 實戰(zhàn)價值
通過 verbose 模式，你可以:
1. 發(fā)現(xiàn)隱藏的依賴沖突
2. 理解 Maven 的仲裁機制
3. 找到被意外覆蓋的版本
4. 優(yōu)化依賴結構
這是排查復雜依賴問題的利器！
?? 用法五：指定模塊（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/
動態(tài)展示項目演化
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
?? 企業(yè)級實戰(zhàn)案例
案例一：Spring 版本沖突排查
問題背景: 項目啟動時報錯: Caused by: java.lang.ClassNotFoundException: org.springframework.util.StringUtils 排查過程: 步驟 1: 查看完整依賴樹 mvn dependency:tree -Dverbose > tree.txt 步驟 2: 搜索 Spring 相關 grep "spring-core" tree.txt 發(fā)現(xiàn): - 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
發(fā)現(xiàn):
- 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 有多個實現(xiàn)，互相沖突
解決:
統(tǒng)一使用 logback:
1. 排除其他實現(xiàn)
2. 只保留 logback
<dependencies>
<!-- 排除 log4j -->
<dependency>
<groupId>xxx</groupId>
<artifactId>xxx</artifactId>
<exclusions>
<exclusion>
<groupId>org.apache.logging.log4j</groupId>
<artifactId>*</artifactId>
</exclusion>
</exclusions>
</dependency>
<!-- 統(tǒng)一使用 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. 按組織分類統(tǒng)計..."
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. 依賴統(tǒng)計
echo "4. 統(tǒng)計依賴數(shù)量..."
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 版本統(tǒng)一
2. 依賴必要性
□ 沒有未使用的依賴
□ 測試依賴 scope 正確
□ 沒有循環(huán)依賴
3. 安全性
□ 無已知安全漏洞
□ 版本不是太老
□ 定期更新依賴
4. 性能優(yōu)化
□ 沒有過大的依賴
□ 傳遞依賴合理
□ 構建時間可接受
?? 福利：常用命令速查表
# 基礎命令 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：只看直接依賴，不管傳遞依賴
現(xiàn)象：pom.xml 看起來很干凈，但項目問題不斷
實際情況：
? 錯誤認知：
我的 pom.xml 只有 10 個直接依賴，很簡潔！
? 殘酷現(xiàn)實：
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 統(tǒng)一管理框架依賴
- ? 排除不必要的傳遞依賴
?? 錯誤 2：忽視 Maven 的"就近原則"
現(xiàn)象：明明指定了版本，但運行時不是這個版本
風險等級: ?? 高危
Maven 仲裁規(guī)則：
路徑最短優(yōu)先（就近原則）: 項目 → A 依賴 → commons-lang3:2.7 項目 → B 依賴 → C 依賴 → commons-lang3:3.12 結果：Maven 選擇 2.7 版本（路徑更短） 即使 3.12 版本更新！ 聲明優(yōu)先原則: 如果路徑長度相同 先聲明的依賴獲勝 <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 依賴
現(xiàn)象：為了減少傳遞依賴，把所有依賴都設為 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
- 打包后缺少必要 jaroptional 的正確理解：
optional=true 的含義:
? 適用場景:
- 可選功能依賴（如插件系統(tǒng)）
- 測試工具依賴
- 特定場景才需要的依賴
? 不適用場景:
- 核心業(yè)務依賴
- 運行時必需的依賴
- 框架基礎依賴
傳遞規(guī)則:
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
現(xiàn)象：編譯通過，運行時失敗
典型場景：
場景一：provided 依賴誤用 <dependency> <groupId>javax.servlet</groupId> <artifactId>javax.servlet-api</artifactId> <scope>provided</scope> <!-- 僅編譯時需要 --> </dependency> 問題： - 本地開發(fā)（Tomcat 提供 servlet API）? 正常 - 打成 fat jar 獨立運行 ? 失敗 - 原因：provided 依賴不會打包 場景二：test 依賴誤用 <dependency> <groupId>junit</groupId> <artifactId>junit</artifactId> <scope>test</scope> <!-- 僅測試時需要 --> </dependency> 問題： - 在 main 代碼中引用了測試類 - 編譯報錯：找不到符號 - 因為 junit 只在測試 classpath
Scope 詳解：
| Scope | 編譯 | 測試 | 運行 | 打包 | 傳遞 |
|---|---|---|---|---|---|
| compile | ? | ? | ? | ? | ? |
| provided | ? | ? | ? | ? | ? |
| runtime | ? | ? | ? | ? | ? |
| test | ? | ? | ? | ? | ? |
| system | ? | ? | ? | ? | ? |
記憶口訣:
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> <!-- ? 數(shù)據庫驅動（運行時才需要） --> <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：依賴樹輸出太多就不管
現(xiàn)象：依賴樹太長（500+ 行），直接放棄分析
實際問題：
大型項目依賴樹: mvn dependency:tree > deps.txt wc -l deps.txt 結果：800+ 行！ 開發(fā)者反應：?? 太多了，不看！ 后果: - 隱藏的版本沖突 - 冗余依賴浪費空間 - 安全風險傳遞 - 構建時間增加
? 高效分析方法：
方法一：分層過濾
# 第一步：只看直接依賴 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 - 圖形化展示 - 識別循環(huán)依賴 - 統(tǒng)計依賴大小 使用技巧: - 右鍵 pom.xml → Open Dependency Visualization - Ctrl+F 搜索特定依賴 - 紅色標記表示沖突
方法四：自動化腳本
#!/bin/bash # check-dependencies.sh echo "=== 依賴統(tǒng)計 ===" mvn dependency:tree | grep -c "^\[INFO\]" | xargs echo "總行數(shù):" echo -e "\n=== 直接依賴 ===" mvn dependency:tree -Ddepth=0 | grep "^\[INFO\] +-" | wc -l | xargs echo "數(shù)量:" 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：不建立依賴審查機制
現(xiàn)象：隨便引入依賴，不考慮后果
團隊協(xié)作災難：
真實案例： 開發(fā) A：引入一個新庫（沒告訴團隊） 開發(fā) B：又引入類似的庫（功能重復） 開發(fā) C：發(fā)現(xiàn)沖突，手動排除 開發(fā) D：不知道為什么要排除，跟著改 半年后: - pom.xml 面目全非 - 各種奇怪的 exclusion - 沒人知道為什么這樣配 - 構建時間從 5 分鐘變 20 分鐘
? 建立依賴審查流程：
流程一：引入新依賴前檢查清單
□ 必要性評估 - 是否真的需要這個依賴？ - 能否用現(xiàn)有依賴實現(xiàn)？ - 是否值得為此增加復雜度？ □ 質量評估 - GitHub Star 數(shù) > 100? - 最后更新時間 < 6 個月？ - 下載量 > 10000/月？ - 有無重大安全漏洞？ □ 兼容性評估 - 與現(xiàn)有依賴版本兼容嗎？ - 會引入沖突嗎？ - 需要排除傳遞依賴嗎？ □ 許可證檢查 - 開源協(xié)議是什么？ - 能商用嗎？ - 需要公開源碼嗎？
流程二：PR/MR 審查要點
Code Review 檢查清單: ? pom.xml 變更 □ 新增依賴是否必要？ □ 版本號是否明確？ □ 是否需要 exclusion？ □ scope 是否正確？ ? 影響評估 □ 構建時間影響？ □ 包體積增加？ □ 是否有破壞性變更？ □ 需要更新文檔嗎？ ? 驗證步驟 □ mvn dependency:tree 檢查 □ mvn dependency:analyze 分析 □ 本地構建測試 □ CI/CD流水線驗證
流程三：定期依賴審計
# 每月執(zhí)行一次依賴健康檢查 # 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
流程四：依賴管理規(guī)范
團隊規(guī)范文檔: 1. 版本管理 - 所有依賴必須明確版本號 - 使用 properties 統(tǒng)一管理 - 禁止使用 LATEST/RELEASE 2. 引入流程 - 提交依賴引入申請 - Tech Lead 審批 - 更新依賴清單文檔 3. 維護責任 - 誰引入誰負責 - 定期更新版本 - 及時修復漏洞 4. 文檔記錄 - 維護依賴清單 - 記錄引入原因 - 標注注意事項
?? 避坑總結
mindmap
root(dependency:tree 避坑指南)
分析視角
不僅看直接依賴
重視傳遞依賴
定期全面檢查
版本仲裁
理解就近原則
使用 dependencyManagement
合理排除沖突
依賴屬性
慎用 optional
正確設置 scope
理解傳遞規(guī)則
方法技巧
分層過濾分析
使用可視化工具
自動化腳本輔助
團隊協(xié)作
建立審查流程
Code Review 把關
定期依賴審計
規(guī)范管理
版本統(tǒng)一管理
引入要審批
文檔要完善?? 互動環(huán)節(jié)
你在依賴管理中遇到過哪些奇葩問題？
歡迎在評論區(qū)分享你的排查經歷和獨門技巧!
常見問題 TOP5:
- 依賴沖突導致 ClassCastException 怎么排查？
- 如何快速找到傳遞依賴的來源？
- dependency:tree 輸出太多怎么看？
- 如何排除不需要的傳遞依賴？
- 多模塊項目中依賴沖突如何處理？
到此這篇關于Maven dependency:tree 的 8 個高級用法的文章就介紹到這了,更多相關Maven dependency:tree高級用法內容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！
相關文章
使用maven倉庫的話需要從網上下載maven的包，比如“apache-maven-3.5.4-bin.tar”，下載完成之后解壓，在解壓的文件夾中的conf目錄下的settings.xml文件夾下就可以配置maven遠程倉庫和本地倉庫的地址2022-11-11
java中 spring 定時任務 實現(xiàn)代碼，需要的朋友可以參考一下2013-03-03
這篇文章主要介紹了Mybatis-Plus自動填充的實現(xiàn)示例,文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2019-08-08
這篇文章主要為大家詳細介紹了Redis介紹和使用場景,需要的朋友可以參考，具體內容如下2018-04-04
Java編程中使用JDBC API連接數(shù)據庫和創(chuàng)建程序的方法
這篇文章主要介紹了Java編程中使用JDBC API連接數(shù)據庫和創(chuàng)建程序的基本教程,JDBC是一種用于執(zhí)行SQL語句的Java API,可以為多種關系數(shù)據庫提供統(tǒng)一訪問需要的朋友可以參考下2015-12-12
這篇文章主要介紹了Spring異常實現(xiàn)統(tǒng)一處理的方法，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習吧2022-12-12
本篇文章主要介紹了Spring boot 集成Dubbox的方法示例，小編覺得挺不錯的，現(xiàn)在分享給大家，也給大家做個參考。一起跟隨小編過來看看吧2018-05-05
SpringBoot引入Thymeleaf的實現(xiàn)方法
這篇文章主要介紹了SpringBoot引入Thymeleaf的實現(xiàn)方法，文中通過示例代碼介紹的非常詳細，對大家的學習或者工作具有一定的參考學習價值，需要的朋友們下面隨著小編來一起學習學習吧2019-04-04
這篇文章主要介紹了java中a=a+1和a+=1的區(qū)別，具有很好的參考價值，希望對大家有所幫助。如有錯誤或未考慮完全的地方，望不吝賜教2021-12-12
本文通過四種方法給大家介紹java命令執(zhí)行jar包的方式，每種方法通過實例代碼給大家詳解，需要的朋友參考下吧2019-11-11