一、背景

在 Java Maven 項目中，我們經(jīng)常會看到不同形式的版本號，例如：

<version>1.0.0-SNAPSHOT</version>
<version>1.0.0</version>
<version>1.0.0-RELEASE</version>

這些版本號看起來差別不大，但在 Maven 構建、依賴管理和生產(chǎn)環(huán)境穩(wěn)定性方面，影響非常明顯。

本文將系統(tǒng)說明 Maven 中的快照版本、正式版本，以及 Nexus 倉庫中的常見規(guī)則和最佳實踐。

二、Maven 中的版本類型

1. SNAPSHOT 快照版本

以 -SNAPSHOT 結尾的版本，稱為快照版本。

示例：

<version>1.0.0-SNAPSHOT</version>

SNAPSHOT 表示該版本仍處于開發(fā)階段，內(nèi)容可能隨時變化。

當快照版本發(fā)布到 Nexus 后，Maven 實際上傳的文件名可能會變成：

demo-1.0.0-20260513.102233-3.jar

但項目中依賴時仍然寫：

<version>1.0.0-SNAPSHOT</version>

Maven 會通過 maven-metadata.xml 找到最新的快照構建。

2. Release 正式版本

不以 -SNAPSHOT 結尾的版本，默認都是正式版本。

示例：

<version>1.0.0</version>

正式版本表示該版本已經(jīng)發(fā)布完成，內(nèi)容應當穩(wěn)定且不可變。

如果發(fā)現(xiàn)問題，不應該覆蓋原來的 1.0.0，而應該發(fā)布新的版本，例如：

1.0.0 -> 1.0.1 -> 1.0.2

3. 只有版本號是什么意思

例如：

<version>1.0.0</version>

這是 Maven 中最標準的正式版本寫法。

而：

<version>1.0.0-RELEASE</version>

雖然也會被 Maven 當作正式版本，但通常沒有必要。因為 Maven 本身已經(jīng)通過是否包含 -SNAPSHOT 來區(qū)分快照版本和正式版本。

三、Nexus 中的倉庫類型

Nexus通常會配置兩個 Maven 倉庫：

常見對應關系如下：

1.0.0-SNAPSHOT -> maven-snapshots
1.0.0          -> maven-releases
1.0.0-RELEASE  -> maven-releases

如果將 SNAPSHOT 版本發(fā)布到 release 倉庫，或者將正式版本發(fā)布到 snapshot 倉庫，Nexus 通常會拒絕上傳。

四、不同版本類型的影響

1. 對構建穩(wěn)定性的影響

SNAPSHOT 版本是可變的，同一個版本號可能對應不同的包內(nèi)容。

這意味著：

<version>1.0.0-SNAPSHOT</version>

今天構建成功，明天可能因為依賴包被重新發(fā)布而失敗。

正式版本則不同：

<version>1.0.0</version>

只要 Nexus 不允許覆蓋，任何時間拉取到的 1.0.0 都應該是同一個內(nèi)容。

2. 對問題排查的影響

如果生產(chǎn)環(huán)境依賴了 SNAPSHOT，出現(xiàn)問題時很難確認當時實際使用的是哪一次構建產(chǎn)物。

正式版本更容易追蹤問題：

服務版本：1.0.1
依賴版本：common-utils-2.3.0
發(fā)布時間：2026-05-13

版本清晰后，日志、部署記錄、制品倉庫和代碼提交記錄才能對應起來。

3. 對團隊協(xié)作的影響

開發(fā)階段使用 SNAPSHOT 可以提升聯(lián)調(diào)效率。

例如公共模塊還在頻繁修改時，業(yè)務項目可以先依賴：

<version>2.0.0-SNAPSHOT</version>

但進入測試驗收或生產(chǎn)發(fā)布階段，應當切換為明確的正式版本：

<version>2.0.0</version>

五、常見問題

1. 生產(chǎn)環(huán)境依賴 SNAPSHOT

這是非常不推薦的做法。

原因包括：

• 構建不可復現(xiàn)
• 包內(nèi)容可能被覆蓋
• 問題排查困難
• 發(fā)布鏈路不可審計

生產(chǎn)環(huán)境應當依賴明確的 release 版本。

2. 重復發(fā)布同一個 release 版本

如果 Nexus 允許覆蓋 release 包，會帶來嚴重風險。

例如第一次發(fā)布的 1.0.0 和第二次覆蓋上傳的 1.0.0 內(nèi)容不同，但版本號完全一樣。

這會導致不同環(huán)境、不同機器、不同時刻拉到的依賴內(nèi)容不一致。

正確做法是：發(fā)現(xiàn)問題 -> 修改代碼 -> 升級版本號 -> 發(fā)布新版本

例如：1.0.0 -> 1.0.1

3. 使用 LATEST 或 RELEASE 作為依賴版本

不建議這樣寫：

<version>LATEST</version>
<version>RELEASE</version>

這種寫法會讓 Maven 自動選擇版本，構建結果不可控?，F(xiàn)代 Maven 項目中應當顯式指定具體版本號。

六、推薦實踐

1. 開發(fā)階段使用 SNAPSHOT

<version>1.1.0-SNAPSHOT</version>

適用于：

• 本地開發(fā)
• 模塊聯(lián)調(diào)
• 測試環(huán)境快速驗證

2. 發(fā)布階段使用正式版本

<version>1.1.0</version>

適用于：

• 測試驗收
• 預發(fā)環(huán)境
• 生產(chǎn)環(huán)境
• 對外發(fā)布的公共組件

3. Release 倉庫禁止覆蓋

Nexus 中建議配置 release 倉庫不允許重復部署。

這樣可以保證：

• 版本不可變
• 構建可復現(xiàn)
• 問題可追蹤
• 發(fā)布鏈路更可靠

4. 版本號保持簡潔

推薦：

1.0.0
1.0.1
1.1.0
2.0.0

不推薦無必要地寫成：

1.0.0-RELEASE

因為 1.0.0 本身已經(jīng)是正式版本。

七、總結

Maven 中判斷快照版本和正式版本的核心規(guī)則非常簡單：

只有以 -SNAPSHOT 結尾的版本才是快照版本，其他版本默認都是正式版本。

SNAPSHOT 適合開發(fā)和聯(lián)調(diào)，特點是靈活但不穩(wěn)定。

Release 適合正式發(fā)布，特點是穩(wěn)定、可追蹤、可復現(xiàn)。

最終推薦規(guī)范如下：

• 開發(fā)版本：1.0.1-SNAPSHOT
• 正式版本：1.0.1
• 修復版本：1.0.2

良好的版本管理不僅能減少依賴沖突，也能提升構建穩(wěn)定性、發(fā)布可靠性和線上問題排查效率。

到此這篇關于Maven版本管理之SNAPSHOT,Release與Nexus倉庫的區(qū)別和影響詳解的文章就介紹到這了,更多相關Maven版本管理內(nèi)容請搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關文章希望大家以后多多支持腳本之家！

最新評論