1. 先搞清楚Maven到底是個什么東西看到“Maven 3.8.8 安裝”這個標題如果你還只是停留在“下載一個壓縮包、解壓、配個環(huán)境變量”這一步那我建議你先別急著動手。Maven絕不是一個“只能幫你下載Jar包的工具”它是整個Java后端工程化體系的基石之一。我見過太多人把Maven當成“網(wǎng)盤”用——項目缺什么包就搜什么坐標根本不去理解它是怎么把你的源碼變成可運行產(chǎn)物的結(jié)果換一個環(huán)境、換一個IDE項目就原地爆炸。Maven的核心價值可以用三句話概括第一它通過pom.xml文件對項目進行“中央集權(quán)”式的管理所有依賴、插件、構(gòu)建配置全部集中在這一個文件里第二它定義了一套標準的生命周期validate、compile、test、package、install、deploy你只需要執(zhí)行mvn clean install它就會按部就班地幫你完成編譯、測試、打包、安裝第三它依賴本地倉庫和遠程倉庫的機制做依賴管理說白了就是“自動下載自動引用”你不需要再手動把一堆Jar包拷進lib目錄。那為什么現(xiàn)在很多人專門搜“Maven 3.8.8”這個版本因為3.8.8是一個非常有代表性的穩(wěn)定版本。它處于3.8.x系列后期修復了不少HTTP嚴格安全問題同時默認配置對JDK 8到JDK 17的兼容性都做得不錯。你在搜索引擎里看到的熱詞“maven與jdk版本對應(yīng)關(guān)系”也側(cè)面說明了一個現(xiàn)實Maven版本和JDK版本不匹配是新手最容易踩的坑。這篇內(nèi)容不是讓你看完就只會“裝個Maven”而是希望你把“安裝、配置、排錯”這一整套動作背后的邏輯搞清楚。不管你是剛接觸Java的在校生還是從Eclipse轉(zhuǎn)IDEA的老開發(fā)甚至是要在Mac上從頭搭建構(gòu)建環(huán)境的運維這篇內(nèi)容都能直接拿來用。我把Windows和Mac兩條線都講透再從本地倉庫講到阿里云鏡像最后聊一聊IDEA集成時那些“默認配置偷走你時間”的坑。2. 安裝前的版本取舍與風險認知2.1 為什么是3.8.8而不是3.9.x或者4.x先說結(jié)論如果你不是非要吃螃蟹建議就以3.8.8為基準。很多人看到Apache官網(wǎng)最新版已經(jīng)到3.9.x甚至更高就會下意識想“是不是越新越好”。實際上Maven是一個極其成熟、幾乎處于“敵對狀態(tài)”的構(gòu)建工具——它的核心功能幾十年來沒有大的變化新版本更多是在修補邊緣問題而不是引入革命性體驗。3.8.8這個版本的定位很有意思。它在3.8.x系列中處于“收尾穩(wěn)定期”相比3.8.1、3.8.3多了很多針對HTTP倉庫訪問的安全策略調(diào)整還修復了Windows環(huán)境下路徑解析的若干問題。而且它和IDEA內(nèi)置Maven的版本可以無縫銜接你在IDEA里直接使用自己安裝的3.8.8不會出現(xiàn)“內(nèi)置版本和外部版本切換后依賴結(jié)構(gòu)失效”的尷尬情況。還有一個現(xiàn)實因素很多企業(yè)級項目、老項目的pom.xml都不會指定Maven版本它們只是依賴你本機裝的那個版本去構(gòu)建。如果你貿(mào)然用一個太新的Maven某些老插件尤其是一些自定義插件或者舊版maven-compiler-plugin可能會出現(xiàn)兼容問題。而3.8.8在中央倉庫中已經(jīng)積累了海量的適配案例你踩到坑后基本上能找到現(xiàn)成的解決方案。如果把版本升到3.9.x一些冷門報錯連百度都搜不出幾條像樣的結(jié)果——這就是“穩(wěn)定”的真實含義。2.2 JDK版本與Maven版本對應(yīng)關(guān)系不匹配引發(fā)的“慢性病”有人會問“Maven和JDK還有什么對應(yīng)關(guān)系不是能用就行嗎”這里面的坑屬于典型的“平時不炸一炸就大事不妙”。Maven本身是Java寫的所以它運行需要一個JRE/JDK環(huán)境。3.8.8要求JDK 8及以上才能運行推薦JDK 8或JDK 11。如果你機器上裝的是JDK 17甚至JDK 21Maven也能跑但這時候你就要考慮項目本身的編譯目標——pom.xml里的maven.compiler.source和maven.compiler.target如果寫的1.8那你用的JDK 17編譯時雖然可以加--add-opens之類的參數(shù)硬啃下來但很多老項目的反射、動態(tài)代理代碼很可能在運行時直接報InaccessibleObjectException。我曾經(jīng)幫同事排查過一個服務(wù)啟動失敗他JDK 17配的Maven是用Homebrew順手裝的3.9.x項目是SSM架構(gòu)的老系統(tǒng)。啟動時直接拋出模塊訪問限制相關(guān)錯誤查了半天最后把JDK換回8或者11問題徹底消失。這并不是說新版不好而是任何工具鏈工作要講究“組合匹配”。如果你的項目是Spring Boot 2.xJDK 8或11是最穩(wěn)的如果項目是Spring Boot 3.x那才需要JDK 17。所以在你執(zhí)行Maven安裝之前先用java -version看一下當前生效的JDK是多少不要到后面“你裝的Maven版本和你項目需要的JDK版本錯位”再去翻車。3. Maven 3.8.8 下載與安裝實操Windows macOS3.1 下載入口與壓縮包選擇Maven官網(wǎng)的下載入口是maven.apache.org/download.cgi別看頁面長得簡陋上面會有兩個主要選項Binary tar.gz archive和Binary zip archive。Windows用戶直接下apache-maven-3.8.8-bin.zipmacOS用戶下tar.gz格式也行zip格式也能解壓其實兩者內(nèi)容一模一樣只是打包格式不同。還有一種source包那個是源碼不要下除非你是要自己編譯Maven否則純屬浪費表情。下載完不要直接扔到C盤根目錄就完事。我一般會建議在非系統(tǒng)盤建一個統(tǒng)一的開發(fā)工具目錄比如Windows下的D:\DevTools\mavenmacOS下的~/DevTools/maven。這樣做的原因有兩個一是盡量讓路徑里不帶空格和中文避免某些老舊的插件解析路徑時出現(xiàn)詭異報錯二是以后你需要裝多個Maven版本做對比測試時目錄結(jié)構(gòu)清晰切換也方便。3.2 Windows環(huán)境變量配置與驗證解壓完成后進入系統(tǒng)環(huán)境變量設(shè)置。這里有個細節(jié)你可以在“系統(tǒng)變量”新建一個MAVEN_HOME指向解壓后的目錄例如D:\DevTools\apache-maven-3.8.8然后在Path里追加%MAVEN_HOME%\bin。有人會覺得只配Path就夠了沒必要單獨配MAVEN_HOME。但是很多第三方工具比如IDEA的Maven Runner、Jenkins的全局配置還是習慣讀取MAVEN_HOME所以建議保留這一項兼容性最好。配置完成后關(guān)鍵的驗證步驟重開一個CMD窗口千萬不要用舊窗口因為環(huán)境變量不會自動刷新輸入mvn -v看到類似這樣的輸出才算成功Apache Maven 3.8.8 (b4d89b6b5d8b9c8d0e8f...) Maven home: D:\DevTools\apache-maven-3.8.8 Java version: 1.8.0_202, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.8.0_202 Default locale: zh_CN, platform encoding: GBK這里要特別留意platform encoding那一行。如果顯示的是GBK或者ANSI你的項目在編譯時如果沒有顯式指定編碼就可能出現(xiàn)亂碼問題。推薦設(shè)置一個系統(tǒng)環(huán)境變量MAVEN_OPTS值為-Dfile.encodingUTF-8可以極大緩解中文系統(tǒng)上Maven輸出和編譯亂碼的“玄學問題”。我在實際配置中還發(fā)現(xiàn)過一種情況mvn -v能正常執(zhí)行但是一運行mvn clean install就提示“MavenHome is not a directory”。這種多半是環(huán)境變量MAVEN_HOME末尾多了一個斜杠或者空格Windows的路徑解析會把它當成一個無效值。所以在修改環(huán)境變量時要養(yǎng)成好習慣不要有多余空格不要帶中文路徑不要在路徑末尾加反斜杠。3.3 macOS環(huán)境變量配置與驗證macOS上配置Maven核心邏輯和Windows一樣但有個更簡便的方法如果你裝了Homebrew直接brew install maven也行但那樣裝的可能不是3.8.8而是Homebrew倉庫里當前最新的穩(wěn)定版。如果你想鎖定3.8.8還是建議手動下載解壓然后編輯~/.zshrc如果是之前的bash環(huán)境就編輯~/.bash_profile。在~/.zshrc里追加export MAVEN_HOME~/DevTools/apache-maven-3.8.8 export PATH$MAVEN_HOME/bin:$PATH追加完成后執(zhí)行source ~/.zshrc然后運行mvn -v。macOS上經(jīng)常出現(xiàn)的坑是“command not found”原因基本是export PATH寫錯了順序把Maven的bin目錄放到了$PATH后面導致系統(tǒng)優(yōu)先找到別的路徑下的舊版本。另一種坑是~/.zshrc新開終端時沒有自動加載這是因為終端進程是從舊的環(huán)境變量派生的你必須重新開一個Terminal窗口或者執(zhí)行exec zsh -l重新登錄Shell。mac上還有一點和Windows不同Maven默認JDK版本可能不是你需要的版本。你可以通過設(shè)置JAVA_HOME來指定Maven構(gòu)建時用的JDK。在~/.zshrc里可以動態(tài)設(shè)置export JAVA_HOME$(/usr/libexec/java_home -v 11)如果你想在Maven 3.8.8、JDK 8、JDK 11之間快速切換建議不要寫死而是維護一個切換腳本。我試過在項目根目錄放一個.env.sh文件里面聲明當前項目需要的JAVA_HOME每次構(gòu)建前source一下。這樣比全局寫死靈活太多尤其是你在同一個電腦上可能同時維護Spring Boot 2.1的老項目和Spring Boot 3.1的新項目時這個技巧能救你一命。4. 核心中的核心settings.xml配置4.1 本地倉庫路徑為什么要改Maven本地倉庫默認在C:\Users\你的用戶名\.m2\repositoryWindows或~/.m2/repositorymacOS/Linux。對于絕大多數(shù)人這個默認位置都是個坑。首先C盤容量很容易被依賴包塞滿一個中型Spring Cloud項目經(jīng)過幾次依賴版本迭代本地倉庫輕松突破10GB。其次以后如果你重裝系統(tǒng)或遷移開發(fā)環(huán)境默認路徑下的配置和倉庫清理起來特別麻煩。所以我拿到新的Maven后打開conf/settings.xml第一件事就是找到localRepository這個標簽把它改成你想放的路徑。這里我一般會在D盤或者macOS的~/DevTools下建一個maven-repository目錄然后寫成localRepositoryD:\DevTools\maven-repository/localRepository注意localRepository的標簽如果注釋掉Maven就會走默認的.m2/repository路徑。很多人在網(wǎng)上看到的教程只會說“改一下就行”但沒人告訴你改完之后原來的C盤倉庫里的包不會被自動遷移你必須手動把舊倉庫里的內(nèi)容復制到新路徑否則之前下載過的依賴又要重新下一遍。那種體驗實在太痛苦。4.2 阿里云鏡像配置與依賴下載加速Maven默認從中央倉庫repo.maven.apache.org下載依賴。在國內(nèi)環(huán)境下中央倉庫的速度時好時壞慢的時候一個依賴下載能卡到你懷疑人生。這時候配置阿里云鏡像倉庫是最有效的方案。在settings.xml里的mirrors節(jié)點下添加mirror idaliyunmaven/id mirrorOf*/mirrorOf name阿里云公共倉庫/name urlhttps://maven.aliyun.com/repository/public/url /mirror這段配置的含義是所有倉庫的請求都鏡像指向阿里云的公共倉庫地址。如果你有多個私服或者特殊倉庫需求比如公司內(nèi)部Nexus倉庫不要用mirrorOf*/mirrorOf而是要根據(jù)倉庫id做精細化配置。阿里云的這個公共倉庫已經(jīng)聚合了Maven中央倉庫、JCenter、Google等多部分內(nèi)容對于日常Java項目開發(fā)夠用了。實際用下來阿里云鏡像在晚高峰、下班高峰期表現(xiàn)依然穩(wěn)定但偶爾也會出現(xiàn)報錯Could not transfer artifact ... Connection reset。這種情況不用緊張多半是網(wǎng)絡(luò)抖動導致的瞬時失敗直接重新執(zhí)行構(gòu)建命令就好。如果你在做持續(xù)集成建議在settings.xml中配置重試機制例如在mirrors后面加上profiles profile idaliyun/id repositories repository idaliyun-public/id urlhttps://maven.aliyun.com/repository/public/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots /repository /repositories /profile /profiles activeProfiles activeProfilealiyun/activeProfile /activeProfiles這樣可以確保一些沒有在mirrors層生效的倉庫請求也能走阿里云。很多人配了鏡像但下載速度還是跟蝸牛一樣大概率就是只配了mirrors而沒加activeProfile或者兩者配置的倉庫id不一致依賴被同時請求了多個倉庫源。4.3 多鏡像倉庫與私服Nexus共存的心得如果你的公司使用了Nexus私服并且你需要同時訪問公司私服和阿里云鏡像就不要再讓mirrorOf匹配所有倉庫了。比如你有一個公司的私服倉庫id是nexus-repo那么可以這樣配mirror idaliyunmaven/id mirrorOf*,!nexus-repo/mirrorOf urlhttps://maven.aliyun.com/repository/public/url /mirror這里的!nexus-repo表示排除這個私服倉庫。同時在profiles中把公司私服的repository配置好。這個組合在實際企業(yè)開發(fā)中非常常見但很多教程壓根沒講。如果你不做這個排除配置公司私服里的內(nèi)部構(gòu)件要么下載失敗要么被阿里云鏡像強制代理導致鑒權(quán)失敗排查起來煩死人。還有一個小技巧在settings.xml中配置servers節(jié)點如果私服需要賬號密碼可以在這里維護。Maven對服務(wù)器密碼保存會做加密需要配置settings-security.xml來解密這個操作比較麻煩但如果你是在本地開發(fā)環(huán)境使用直接明文填寫也無妨。如果是在公司統(tǒng)一托管環(huán)境里建議詢問運維是否有獨立的安全配置規(guī)范。5. 本地倉庫、IDEA集成與Maven項目實戰(zhàn)5.1 IDEA中如何使用自己安裝的Maven而不是內(nèi)置的IDEA確實自帶了Maven但自帶版本通常落后于你手動安裝的版本而且它默認使用的settings.xml是IDEA目錄下的一個內(nèi)部配置文件。如果你直接用IDEA默認配置你會發(fā)現(xiàn)自己在conf/settings.xml里做的鏡像、本地倉庫配置基本不起作用——因為IDEA根本沒有讀取那個配置文件。正確的做法打開IDEA的Settings搜索Maven找到Maven home path選擇你手動安裝的3.8.8目錄然后在User settings file中指定到你的settings.xml路徑勾選Override。這一步非常關(guān)鍵很多人明明在命令行里mvn install好好的到了IDEA里就瘋狂報“Could not find artifact”十有八九就是IDEA還在使用它自帶的Maven和空白的settings.xml。此外IDEA的Runner設(shè)置中有一項Environment variables建議加上JAVA_HOME指向?qū)?yīng)JDK并設(shè)置MAVEN_OPTS為-Xmx1024m等參數(shù)避免大型項目編譯時內(nèi)存不足。實測下來一個包含幾十個微服務(wù)模塊的工程在IDEA中構(gòu)建時默認的512MB堆內(nèi)存根本不夠用OOM報錯只是時間問題。5.2 用Maven 3.8.8構(gòu)建一個命令行clean install工程這節(jié)適合所有剛配好Maven的人去驗證自己的環(huán)境是否“真的能用”。隨便找一個已有的Maven項目或者自己建一個最簡單的webapp然后在項目根目錄執(zhí)行mvn clean install觀察控制臺日志重點關(guān)注這幾個階段downloading ...階段如果日志卡在下載階段說明鏡像配置有問題需要回去檢查settings.xml的url到底是http還是https。阿里云要求用https用http會得到301重定向新版本的Maven出于安全考慮會直接拒絕。compiling階段如果編譯報錯先看JDK版本是否匹配。我在前面強調(diào)過Maven 3.8.8配合JDK 8和11最穩(wěn)你非要用JDK 17就需要在pom.xml中顯式聲明java.version為17同時升級maven-compiler-plugin到3.10.0以上。這是很多人“mvn install失敗”的隱藏原因。package和install階段成功后在target目錄下會生成Jar包或War包。這里分享一個我自己的習慣在CI/CD環(huán)境或者需要快速驗證依賴是否完整時我會直接執(zhí)行mvn clean install -DskipTests跳過測試可以大幅縮短構(gòu)建時間但在本地開發(fā)還是建議不要頻繁跳過單元測試畢竟測試也是一種對依賴配置的驗證。你可以配合-pl參數(shù)只構(gòu)建指定模塊比如mvn clean install -pl user-service -am-am的意思是also make會同時構(gòu)建被依賴的前置模塊。這個組合在多模塊項目中效率極高比每次構(gòu)建整個工程快好幾個數(shù)量級。5.3 常見紅線不要在JDK與Maven版本上“自由發(fā)揮”我在幫人排查問題的時候發(fā)現(xiàn)很多人會用IDEA的Project Structure隨意切換SDK版本但Maven的編譯行為是獨立的——它遵行的不是IDEA的Project SDK而是JAVA_HOME和pom.xml里maven.compiler.source/target的配置。如果你感覺IDEA里面一切正常但命令行mvn clean install就是各種報錯優(yōu)先檢查mvn -v顯示的Java版本是不是你預(yù)期的那個。還有一個紅線不要用install階段的pluginManagement去隨意覆蓋中央插件版本尤其是maven-surefire-plugin和maven-compiler-plugin。它們和JDK版本的搭配有著嚴格的兼容性矩陣如果你在pom.xml里硬指定一個過老的maven-compiler-plugin版本而JDK是17編譯階段會直接報“invalid source release”。我建議初次使用Maven 3.8.8時先不要畫蛇添足改這些插件的版本讓Maven使用它默認綁定的插件版本跑通了再考慮優(yōu)化。6. 實戰(zhàn)過程中我踩過、你也可能會踩的坑6.1 maven下載依賴報錯“Could not transfer artifact”的排查順序這個報錯應(yīng)該是出現(xiàn)頻率最高的問題了。我剛裝好Maven那會兒跑到一個老項目里執(zhí)行mvn clean結(jié)果一堆依賴報傳輸錯誤。我的排查邏輯分享給你第一步先確認網(wǎng)絡(luò)能不能連通Maven倉庫地址比如用瀏覽器訪問https://maven.aliyun.com/repository/public如果能訪問說明網(wǎng)絡(luò)沒問題。第二步確認是不是SSL證書問題。Maven 3.8.8對證書校驗比舊版嚴格如果你配置的倉庫地址是http而不是https或者公司內(nèi)網(wǎng)使用了自簽名證書那么會在握手階段直接失敗。這時候可以在settings.xml里給MAVEN_OPTS加上-Dmaven.wagon.http.ssl.insecuretrue但注意這只適合內(nèi)網(wǎng)測試生產(chǎn)環(huán)境別這么干。第三步確認本地倉庫是否有半成品文件。Maven下載過程中如果遇到斷網(wǎng)會在本地倉庫留下.lastUpdated后綴的文件這會導致下次構(gòu)建時Maven誤以為已經(jīng)嘗試過下載但失敗從而不再發(fā)起新請求。解決辦法是把repository目錄中所有.lastUpdated文件刪掉或者用一個命令清理持久化失敗的記錄find ~/.m2/repository -name *.lastUpdated -type f -delete這個命令在macOS/Linux下非常好用。Windows下可以用PowerShell的Get-ChildItem -Recurse | Where-Object { $_.Name -like *.lastUpdated } | Remove-Item。但如果你已經(jīng)配置了自定義本地倉庫記得把路徑替換成你的倉庫路徑。6.2 配置了阿里云鏡像但依賴還是很慢不一定是鏡像的鍋有段時間我開發(fā)一個Spring Cloud Alibaba項目依賴特別多配置了阿里云鏡像后第一次構(gòu)建仍然花了二十多分鐘。我以為是鏡像失效了后來盯著控制臺才發(fā)現(xiàn)卡住的不是外部依賴而是公司私服里的內(nèi)部構(gòu)件——因為我在mirrorOf中用了*把所有請求都轉(zhuǎn)發(fā)到了阿里云結(jié)果公司私服的jar包在阿里云上不存在Maven反復重試直到超時。解決方法是回到第4.3節(jié)說的排除規(guī)則用*,!nexus-repo這種寫法。此外還有一個不起眼但影響巨大的參數(shù)id的命名。Maven判定鏡像是否生效并不完全看url還要看鏡像倉庫的id是否和目標倉庫id一致。很多人在網(wǎng)上復制配置根本沒看id的值結(jié)果是鏡像配置存在但從未真正生效。判斷方法很簡單執(zhí)行mvn help:effective-settings它會列出你最終生效的settings.xml內(nèi)容檢查mirror節(jié)點是否和實際請求匹配。6.3 IDEA和命令行構(gòu)建結(jié)果不一致的真相同一個項目命令行mvn clean install成功IDEA構(gòu)建卻報錯或者反過來IDEA能構(gòu)建命令行徹底失敗。這種“陰陽兩隔”的現(xiàn)象十個里有九個是因為Maven的執(zhí)行者不一樣。IDEA默認是多模塊遞歸構(gòu)建它調(diào)用Maven時會把-T 1C之類的并行參數(shù)加進去還會自動設(shè)置-Dmaven.repo.local從Maven設(shè)置面板讀取本地倉庫路徑。如果你在IDEA的Maven設(shè)置面板中填寫的路徑和你命令行settings.xml里配置的localRepository不一致那么兩個環(huán)境會各自使用不同的本地倉庫緩存表面看起來都是報“missing artifact”實際行為卻完全不同。排查這類問題我建議你在IDEA中進入Help - Show Log in Explorer查看IDEA日志中maven插件的執(zhí)行具體參數(shù)你就能看到它到底加了什么、用了哪個settings.xml。6.4 安裝完Maven后執(zhí)行mvn -v出現(xiàn)“不是內(nèi)部或外部命令”這個典型問題通常出現(xiàn)在Windows上常見原因有兩個一是環(huán)境變量配置完成后打開的CMD窗口是舊的沒有加載新變量二是系統(tǒng)變量的Path中%MAVEN_HOME%\bin的先后順序出現(xiàn)問題——如果Path中其他目錄里有一個同名mvn.cmd或者系統(tǒng)里存在另一個Maven包CMD會根據(jù)順序優(yōu)先執(zhí)行先命中的那個。解決辦法確認echo %MAVEN_HOME%能打印正確路徑然后where mvn查看到底找到的是哪個路徑下的mvn。macOS用戶如果出現(xiàn)command not found優(yōu)先檢查~/.zshrc是否有權(quán)限問題或者語法錯誤比如export PATH$MAVEN_HOME/bin:$PATH寫成了export PATH$PATH:$MAVEN_HOME/bin前者優(yōu)先使用Maven的bin目錄而后者如果你當前環(huán)境變量里已經(jīng)有一個舊Maven路徑可能會被舊版本“劫持”。7. 給不同使用場景的最終建議如果你只是做一個Spring Boot的學習項目Maven 3.8.8加上阿里云鏡像十分鐘內(nèi)就能搞定環(huán)境用起來完全夠。如果你是企業(yè)開發(fā)或老項目維護請多留意JDK版本和插件版本盡量不要在Maven本身做激進升級。如果你是長期從事Java開發(fā)的工程師我強烈建議你好好讀一遍settings.xml里的注釋那些英文注釋雖然啰嗦但一個字一個字看完你對Maven的理解會上一個臺階。最后分享一下我現(xiàn)在的工作習慣在每臺開發(fā)機上我會把Maven的settings.xml放在一個獨立目錄比如~/maven-conf/settings.xml然后通過MAVEN_HOME和IDE配置同時指向它。這樣不管我在哪臺機器、哪個項目上工作行為都保持一致。配置里面除了本地倉庫、鏡像我還會把offline設(shè)置為false因為我不希望Maven在倉庫緩存崩潰時自動進入離線狀態(tài)那會讓后續(xù)排查變成“大海撈針”。Maven 3.8.8的安裝只是起點真正要花時間去琢磨的是你怎么通過依賴管理把項目從“能跑”變成“能長期維護”。環(huán)境搭好后找一個小項目親手跑幾遍clean install把下載、編譯、打包、安裝的日志從頭到尾看一遍你會收獲比任何教程都多的實踐經(jīng)驗。 Maven 3.8.8安裝配置與避坑指南
1. 先搞清楚Maven到底是個什么東西看到“Maven 3.8.8 安裝”這個標題如果你還只是停留在“下載一個壓縮包、解壓、配個環(huán)境變量”這一步那我建議你先別急著動手。Maven絕不是一個“只能幫你下載Jar包的工具”它是整個Java后端工程化體系的基石之一。我見過太多人把Maven當成“網(wǎng)盤”用——項目缺什么包就搜什么坐標根本不去理解它是怎么把你的源碼變成可運行產(chǎn)物的結(jié)果換一個環(huán)境、換一個IDE項目就原地爆炸。Maven的核心價值可以用三句話概括第一它通過pom.xml文件對項目進行“中央集權(quán)”式的管理所有依賴、插件、構(gòu)建配置全部集中在這一個文件里第二它定義了一套標準的生命周期validate、compile、test、package、install、deploy你只需要執(zhí)行mvn clean install它就會按部就班地幫你完成編譯、測試、打包、安裝第三它依賴本地倉庫和遠程倉庫的機制做依賴管理說白了就是“自動下載自動引用”你不需要再手動把一堆Jar包拷進lib目錄。那為什么現(xiàn)在很多人專門搜“Maven 3.8.8”這個版本因為3.8.8是一個非常有代表性的穩(wěn)定版本。它處于3.8.x系列后期修復了不少HTTP嚴格安全問題同時默認配置對JDK 8到JDK 17的兼容性都做得不錯。你在搜索引擎里看到的熱詞“maven與jdk版本對應(yīng)關(guān)系”也側(cè)面說明了一個現(xiàn)實Maven版本和JDK版本不匹配是新手最容易踩的坑。這篇內(nèi)容不是讓你看完就只會“裝個Maven”而是希望你把“安裝、配置、排錯”這一整套動作背后的邏輯搞清楚。不管你是剛接觸Java的在校生還是從Eclipse轉(zhuǎn)IDEA的老開發(fā)甚至是要在Mac上從頭搭建構(gòu)建環(huán)境的運維這篇內(nèi)容都能直接拿來用。我把Windows和Mac兩條線都講透再從本地倉庫講到阿里云鏡像最后聊一聊IDEA集成時那些“默認配置偷走你時間”的坑。2. 安裝前的版本取舍與風險認知2.1 為什么是3.8.8而不是3.9.x或者4.x先說結(jié)論如果你不是非要吃螃蟹建議就以3.8.8為基準。很多人看到Apache官網(wǎng)最新版已經(jīng)到3.9.x甚至更高就會下意識想“是不是越新越好”。實際上Maven是一個極其成熟、幾乎處于“敵對狀態(tài)”的構(gòu)建工具——它的核心功能幾十年來沒有大的變化新版本更多是在修補邊緣問題而不是引入革命性體驗。3.8.8這個版本的定位很有意思。它在3.8.x系列中處于“收尾穩(wěn)定期”相比3.8.1、3.8.3多了很多針對HTTP倉庫訪問的安全策略調(diào)整還修復了Windows環(huán)境下路徑解析的若干問題。而且它和IDEA內(nèi)置Maven的版本可以無縫銜接你在IDEA里直接使用自己安裝的3.8.8不會出現(xiàn)“內(nèi)置版本和外部版本切換后依賴結(jié)構(gòu)失效”的尷尬情況。還有一個現(xiàn)實因素很多企業(yè)級項目、老項目的pom.xml都不會指定Maven版本它們只是依賴你本機裝的那個版本去構(gòu)建。如果你貿(mào)然用一個太新的Maven某些老插件尤其是一些自定義插件或者舊版maven-compiler-plugin可能會出現(xiàn)兼容問題。而3.8.8在中央倉庫中已經(jīng)積累了海量的適配案例你踩到坑后基本上能找到現(xiàn)成的解決方案。如果把版本升到3.9.x一些冷門報錯連百度都搜不出幾條像樣的結(jié)果——這就是“穩(wěn)定”的真實含義。2.2 JDK版本與Maven版本對應(yīng)關(guān)系不匹配引發(fā)的“慢性病”有人會問“Maven和JDK還有什么對應(yīng)關(guān)系不是能用就行嗎”這里面的坑屬于典型的“平時不炸一炸就大事不妙”。Maven本身是Java寫的所以它運行需要一個JRE/JDK環(huán)境。3.8.8要求JDK 8及以上才能運行推薦JDK 8或JDK 11。如果你機器上裝的是JDK 17甚至JDK 21Maven也能跑但這時候你就要考慮項目本身的編譯目標——pom.xml里的maven.compiler.source和maven.compiler.target如果寫的1.8那你用的JDK 17編譯時雖然可以加--add-opens之類的參數(shù)硬啃下來但很多老項目的反射、動態(tài)代理代碼很可能在運行時直接報InaccessibleObjectException。我曾經(jīng)幫同事排查過一個服務(wù)啟動失敗他JDK 17配的Maven是用Homebrew順手裝的3.9.x項目是SSM架構(gòu)的老系統(tǒng)。啟動時直接拋出模塊訪問限制相關(guān)錯誤查了半天最后把JDK換回8或者11問題徹底消失。這并不是說新版不好而是任何工具鏈工作要講究“組合匹配”。如果你的項目是Spring Boot 2.xJDK 8或11是最穩(wěn)的如果項目是Spring Boot 3.x那才需要JDK 17。所以在你執(zhí)行Maven安裝之前先用java -version看一下當前生效的JDK是多少不要到后面“你裝的Maven版本和你項目需要的JDK版本錯位”再去翻車。3. Maven 3.8.8 下載與安裝實操Windows macOS3.1 下載入口與壓縮包選擇Maven官網(wǎng)的下載入口是maven.apache.org/download.cgi別看頁面長得簡陋上面會有兩個主要選項Binary tar.gz archive和Binary zip archive。Windows用戶直接下apache-maven-3.8.8-bin.zipmacOS用戶下tar.gz格式也行zip格式也能解壓其實兩者內(nèi)容一模一樣只是打包格式不同。還有一種source包那個是源碼不要下除非你是要自己編譯Maven否則純屬浪費表情。下載完不要直接扔到C盤根目錄就完事。我一般會建議在非系統(tǒng)盤建一個統(tǒng)一的開發(fā)工具目錄比如Windows下的D:\DevTools\mavenmacOS下的~/DevTools/maven。這樣做的原因有兩個一是盡量讓路徑里不帶空格和中文避免某些老舊的插件解析路徑時出現(xiàn)詭異報錯二是以后你需要裝多個Maven版本做對比測試時目錄結(jié)構(gòu)清晰切換也方便。3.2 Windows環(huán)境變量配置與驗證解壓完成后進入系統(tǒng)環(huán)境變量設(shè)置。這里有個細節(jié)你可以在“系統(tǒng)變量”新建一個MAVEN_HOME指向解壓后的目錄例如D:\DevTools\apache-maven-3.8.8然后在Path里追加%MAVEN_HOME%\bin。有人會覺得只配Path就夠了沒必要單獨配MAVEN_HOME。但是很多第三方工具比如IDEA的Maven Runner、Jenkins的全局配置還是習慣讀取MAVEN_HOME所以建議保留這一項兼容性最好。配置完成后關(guān)鍵的驗證步驟重開一個CMD窗口千萬不要用舊窗口因為環(huán)境變量不會自動刷新輸入mvn -v看到類似這樣的輸出才算成功Apache Maven 3.8.8 (b4d89b6b5d8b9c8d0e8f...) Maven home: D:\DevTools\apache-maven-3.8.8 Java version: 1.8.0_202, vendor: Oracle Corporation Java home: C:\Program Files\Java\jdk1.8.0_202 Default locale: zh_CN, platform encoding: GBK這里要特別留意platform encoding那一行。如果顯示的是GBK或者ANSI你的項目在編譯時如果沒有顯式指定編碼就可能出現(xiàn)亂碼問題。推薦設(shè)置一個系統(tǒng)環(huán)境變量MAVEN_OPTS值為-Dfile.encodingUTF-8可以極大緩解中文系統(tǒng)上Maven輸出和編譯亂碼的“玄學問題”。我在實際配置中還發(fā)現(xiàn)過一種情況mvn -v能正常執(zhí)行但是一運行mvn clean install就提示“MavenHome is not a directory”。這種多半是環(huán)境變量MAVEN_HOME末尾多了一個斜杠或者空格Windows的路徑解析會把它當成一個無效值。所以在修改環(huán)境變量時要養(yǎng)成好習慣不要有多余空格不要帶中文路徑不要在路徑末尾加反斜杠。3.3 macOS環(huán)境變量配置與驗證macOS上配置Maven核心邏輯和Windows一樣但有個更簡便的方法如果你裝了Homebrew直接brew install maven也行但那樣裝的可能不是3.8.8而是Homebrew倉庫里當前最新的穩(wěn)定版。如果你想鎖定3.8.8還是建議手動下載解壓然后編輯~/.zshrc如果是之前的bash環(huán)境就編輯~/.bash_profile。在~/.zshrc里追加export MAVEN_HOME~/DevTools/apache-maven-3.8.8 export PATH$MAVEN_HOME/bin:$PATH追加完成后執(zhí)行source ~/.zshrc然后運行mvn -v。macOS上經(jīng)常出現(xiàn)的坑是“command not found”原因基本是export PATH寫錯了順序把Maven的bin目錄放到了$PATH后面導致系統(tǒng)優(yōu)先找到別的路徑下的舊版本。另一種坑是~/.zshrc新開終端時沒有自動加載這是因為終端進程是從舊的環(huán)境變量派生的你必須重新開一個Terminal窗口或者執(zhí)行exec zsh -l重新登錄Shell。mac上還有一點和Windows不同Maven默認JDK版本可能不是你需要的版本。你可以通過設(shè)置JAVA_HOME來指定Maven構(gòu)建時用的JDK。在~/.zshrc里可以動態(tài)設(shè)置export JAVA_HOME$(/usr/libexec/java_home -v 11)如果你想在Maven 3.8.8、JDK 8、JDK 11之間快速切換建議不要寫死而是維護一個切換腳本。我試過在項目根目錄放一個.env.sh文件里面聲明當前項目需要的JAVA_HOME每次構(gòu)建前source一下。這樣比全局寫死靈活太多尤其是你在同一個電腦上可能同時維護Spring Boot 2.1的老項目和Spring Boot 3.1的新項目時這個技巧能救你一命。4. 核心中的核心settings.xml配置4.1 本地倉庫路徑為什么要改Maven本地倉庫默認在C:\Users\你的用戶名\.m2\repositoryWindows或~/.m2/repositorymacOS/Linux。對于絕大多數(shù)人這個默認位置都是個坑。首先C盤容量很容易被依賴包塞滿一個中型Spring Cloud項目經(jīng)過幾次依賴版本迭代本地倉庫輕松突破10GB。其次以后如果你重裝系統(tǒng)或遷移開發(fā)環(huán)境默認路徑下的配置和倉庫清理起來特別麻煩。所以我拿到新的Maven后打開conf/settings.xml第一件事就是找到localRepository這個標簽把它改成你想放的路徑。這里我一般會在D盤或者macOS的~/DevTools下建一個maven-repository目錄然后寫成localRepositoryD:\DevTools\maven-repository/localRepository注意localRepository的標簽如果注釋掉Maven就會走默認的.m2/repository路徑。很多人在網(wǎng)上看到的教程只會說“改一下就行”但沒人告訴你改完之后原來的C盤倉庫里的包不會被自動遷移你必須手動把舊倉庫里的內(nèi)容復制到新路徑否則之前下載過的依賴又要重新下一遍。那種體驗實在太痛苦。4.2 阿里云鏡像配置與依賴下載加速Maven默認從中央倉庫repo.maven.apache.org下載依賴。在國內(nèi)環(huán)境下中央倉庫的速度時好時壞慢的時候一個依賴下載能卡到你懷疑人生。這時候配置阿里云鏡像倉庫是最有效的方案。在settings.xml里的mirrors節(jié)點下添加mirror idaliyunmaven/id mirrorOf*/mirrorOf name阿里云公共倉庫/name urlhttps://maven.aliyun.com/repository/public/url /mirror這段配置的含義是所有倉庫的請求都鏡像指向阿里云的公共倉庫地址。如果你有多個私服或者特殊倉庫需求比如公司內(nèi)部Nexus倉庫不要用mirrorOf*/mirrorOf而是要根據(jù)倉庫id做精細化配置。阿里云的這個公共倉庫已經(jīng)聚合了Maven中央倉庫、JCenter、Google等多部分內(nèi)容對于日常Java項目開發(fā)夠用了。實際用下來阿里云鏡像在晚高峰、下班高峰期表現(xiàn)依然穩(wěn)定但偶爾也會出現(xiàn)報錯Could not transfer artifact ... Connection reset。這種情況不用緊張多半是網(wǎng)絡(luò)抖動導致的瞬時失敗直接重新執(zhí)行構(gòu)建命令就好。如果你在做持續(xù)集成建議在settings.xml中配置重試機制例如在mirrors后面加上profiles profile idaliyun/id repositories repository idaliyun-public/id urlhttps://maven.aliyun.com/repository/public/url releases enabledtrue/enabled /releases snapshots enabledtrue/enabled /snapshots /repository /repositories /profile /profiles activeProfiles activeProfilealiyun/activeProfile /activeProfiles這樣可以確保一些沒有在mirrors層生效的倉庫請求也能走阿里云。很多人配了鏡像但下載速度還是跟蝸牛一樣大概率就是只配了mirrors而沒加activeProfile或者兩者配置的倉庫id不一致依賴被同時請求了多個倉庫源。4.3 多鏡像倉庫與私服Nexus共存的心得如果你的公司使用了Nexus私服并且你需要同時訪問公司私服和阿里云鏡像就不要再讓mirrorOf匹配所有倉庫了。比如你有一個公司的私服倉庫id是nexus-repo那么可以這樣配mirror idaliyunmaven/id mirrorOf*,!nexus-repo/mirrorOf urlhttps://maven.aliyun.com/repository/public/url /mirror這里的!nexus-repo表示排除這個私服倉庫。同時在profiles中把公司私服的repository配置好。這個組合在實際企業(yè)開發(fā)中非常常見但很多教程壓根沒講。如果你不做這個排除配置公司私服里的內(nèi)部構(gòu)件要么下載失敗要么被阿里云鏡像強制代理導致鑒權(quán)失敗排查起來煩死人。還有一個小技巧在settings.xml中配置servers節(jié)點如果私服需要賬號密碼可以在這里維護。Maven對服務(wù)器密碼保存會做加密需要配置settings-security.xml來解密這個操作比較麻煩但如果你是在本地開發(fā)環(huán)境使用直接明文填寫也無妨。如果是在公司統(tǒng)一托管環(huán)境里建議詢問運維是否有獨立的安全配置規(guī)范。5. 本地倉庫、IDEA集成與Maven項目實戰(zhàn)5.1 IDEA中如何使用自己安裝的Maven而不是內(nèi)置的IDEA確實自帶了Maven但自帶版本通常落后于你手動安裝的版本而且它默認使用的settings.xml是IDEA目錄下的一個內(nèi)部配置文件。如果你直接用IDEA默認配置你會發(fā)現(xiàn)自己在conf/settings.xml里做的鏡像、本地倉庫配置基本不起作用——因為IDEA根本沒有讀取那個配置文件。正確的做法打開IDEA的Settings搜索Maven找到Maven home path選擇你手動安裝的3.8.8目錄然后在User settings file中指定到你的settings.xml路徑勾選Override。這一步非常關(guān)鍵很多人明明在命令行里mvn install好好的到了IDEA里就瘋狂報“Could not find artifact”十有八九就是IDEA還在使用它自帶的Maven和空白的settings.xml。此外IDEA的Runner設(shè)置中有一項Environment variables建議加上JAVA_HOME指向?qū)?yīng)JDK并設(shè)置MAVEN_OPTS為-Xmx1024m等參數(shù)避免大型項目編譯時內(nèi)存不足。實測下來一個包含幾十個微服務(wù)模塊的工程在IDEA中構(gòu)建時默認的512MB堆內(nèi)存根本不夠用OOM報錯只是時間問題。5.2 用Maven 3.8.8構(gòu)建一個命令行clean install工程這節(jié)適合所有剛配好Maven的人去驗證自己的環(huán)境是否“真的能用”。隨便找一個已有的Maven項目或者自己建一個最簡單的webapp然后在項目根目錄執(zhí)行mvn clean install觀察控制臺日志重點關(guān)注這幾個階段downloading ...階段如果日志卡在下載階段說明鏡像配置有問題需要回去檢查settings.xml的url到底是http還是https。阿里云要求用https用http會得到301重定向新版本的Maven出于安全考慮會直接拒絕。compiling階段如果編譯報錯先看JDK版本是否匹配。我在前面強調(diào)過Maven 3.8.8配合JDK 8和11最穩(wěn)你非要用JDK 17就需要在pom.xml中顯式聲明java.version為17同時升級maven-compiler-plugin到3.10.0以上。這是很多人“mvn install失敗”的隱藏原因。package和install階段成功后在target目錄下會生成Jar包或War包。這里分享一個我自己的習慣在CI/CD環(huán)境或者需要快速驗證依賴是否完整時我會直接執(zhí)行mvn clean install -DskipTests跳過測試可以大幅縮短構(gòu)建時間但在本地開發(fā)還是建議不要頻繁跳過單元測試畢竟測試也是一種對依賴配置的驗證。你可以配合-pl參數(shù)只構(gòu)建指定模塊比如mvn clean install -pl user-service -am-am的意思是also make會同時構(gòu)建被依賴的前置模塊。這個組合在多模塊項目中效率極高比每次構(gòu)建整個工程快好幾個數(shù)量級。5.3 常見紅線不要在JDK與Maven版本上“自由發(fā)揮”我在幫人排查問題的時候發(fā)現(xiàn)很多人會用IDEA的Project Structure隨意切換SDK版本但Maven的編譯行為是獨立的——它遵行的不是IDEA的Project SDK而是JAVA_HOME和pom.xml里maven.compiler.source/target的配置。如果你感覺IDEA里面一切正常但命令行mvn clean install就是各種報錯優(yōu)先檢查mvn -v顯示的Java版本是不是你預(yù)期的那個。還有一個紅線不要用install階段的pluginManagement去隨意覆蓋中央插件版本尤其是maven-surefire-plugin和maven-compiler-plugin。它們和JDK版本的搭配有著嚴格的兼容性矩陣如果你在pom.xml里硬指定一個過老的maven-compiler-plugin版本而JDK是17編譯階段會直接報“invalid source release”。我建議初次使用Maven 3.8.8時先不要畫蛇添足改這些插件的版本讓Maven使用它默認綁定的插件版本跑通了再考慮優(yōu)化。6. 實戰(zhàn)過程中我踩過、你也可能會踩的坑6.1 maven下載依賴報錯“Could not transfer artifact”的排查順序這個報錯應(yīng)該是出現(xiàn)頻率最高的問題了。我剛裝好Maven那會兒跑到一個老項目里執(zhí)行mvn clean結(jié)果一堆依賴報傳輸錯誤。我的排查邏輯分享給你第一步先確認網(wǎng)絡(luò)能不能連通Maven倉庫地址比如用瀏覽器訪問https://maven.aliyun.com/repository/public如果能訪問說明網(wǎng)絡(luò)沒問題。第二步確認是不是SSL證書問題。Maven 3.8.8對證書校驗比舊版嚴格如果你配置的倉庫地址是http而不是https或者公司內(nèi)網(wǎng)使用了自簽名證書那么會在握手階段直接失敗。這時候可以在settings.xml里給MAVEN_OPTS加上-Dmaven.wagon.http.ssl.insecuretrue但注意這只適合內(nèi)網(wǎng)測試生產(chǎn)環(huán)境別這么干。第三步確認本地倉庫是否有半成品文件。Maven下載過程中如果遇到斷網(wǎng)會在本地倉庫留下.lastUpdated后綴的文件這會導致下次構(gòu)建時Maven誤以為已經(jīng)嘗試過下載但失敗從而不再發(fā)起新請求。解決辦法是把repository目錄中所有.lastUpdated文件刪掉或者用一個命令清理持久化失敗的記錄find ~/.m2/repository -name *.lastUpdated -type f -delete這個命令在macOS/Linux下非常好用。Windows下可以用PowerShell的Get-ChildItem -Recurse | Where-Object { $_.Name -like *.lastUpdated } | Remove-Item。但如果你已經(jīng)配置了自定義本地倉庫記得把路徑替換成你的倉庫路徑。6.2 配置了阿里云鏡像但依賴還是很慢不一定是鏡像的鍋有段時間我開發(fā)一個Spring Cloud Alibaba項目依賴特別多配置了阿里云鏡像后第一次構(gòu)建仍然花了二十多分鐘。我以為是鏡像失效了后來盯著控制臺才發(fā)現(xiàn)卡住的不是外部依賴而是公司私服里的內(nèi)部構(gòu)件——因為我在mirrorOf中用了*把所有請求都轉(zhuǎn)發(fā)到了阿里云結(jié)果公司私服的jar包在阿里云上不存在Maven反復重試直到超時。解決方法是回到第4.3節(jié)說的排除規(guī)則用*,!nexus-repo這種寫法。此外還有一個不起眼但影響巨大的參數(shù)id的命名。Maven判定鏡像是否生效并不完全看url還要看鏡像倉庫的id是否和目標倉庫id一致。很多人在網(wǎng)上復制配置根本沒看id的值結(jié)果是鏡像配置存在但從未真正生效。判斷方法很簡單執(zhí)行mvn help:effective-settings它會列出你最終生效的settings.xml內(nèi)容檢查mirror節(jié)點是否和實際請求匹配。6.3 IDEA和命令行構(gòu)建結(jié)果不一致的真相同一個項目命令行mvn clean install成功IDEA構(gòu)建卻報錯或者反過來IDEA能構(gòu)建命令行徹底失敗。這種“陰陽兩隔”的現(xiàn)象十個里有九個是因為Maven的執(zhí)行者不一樣。IDEA默認是多模塊遞歸構(gòu)建它調(diào)用Maven時會把-T 1C之類的并行參數(shù)加進去還會自動設(shè)置-Dmaven.repo.local從Maven設(shè)置面板讀取本地倉庫路徑。如果你在IDEA的Maven設(shè)置面板中填寫的路徑和你命令行settings.xml里配置的localRepository不一致那么兩個環(huán)境會各自使用不同的本地倉庫緩存表面看起來都是報“missing artifact”實際行為卻完全不同。排查這類問題我建議你在IDEA中進入Help - Show Log in Explorer查看IDEA日志中maven插件的執(zhí)行具體參數(shù)你就能看到它到底加了什么、用了哪個settings.xml。6.4 安裝完Maven后執(zhí)行mvn -v出現(xiàn)“不是內(nèi)部或外部命令”這個典型問題通常出現(xiàn)在Windows上常見原因有兩個一是環(huán)境變量配置完成后打開的CMD窗口是舊的沒有加載新變量二是系統(tǒng)變量的Path中%MAVEN_HOME%\bin的先后順序出現(xiàn)問題——如果Path中其他目錄里有一個同名mvn.cmd或者系統(tǒng)里存在另一個Maven包CMD會根據(jù)順序優(yōu)先執(zhí)行先命中的那個。解決辦法確認echo %MAVEN_HOME%能打印正確路徑然后where mvn查看到底找到的是哪個路徑下的mvn。macOS用戶如果出現(xiàn)command not found優(yōu)先檢查~/.zshrc是否有權(quán)限問題或者語法錯誤比如export PATH$MAVEN_HOME/bin:$PATH寫成了export PATH$PATH:$MAVEN_HOME/bin前者優(yōu)先使用Maven的bin目錄而后者如果你當前環(huán)境變量里已經(jīng)有一個舊Maven路徑可能會被舊版本“劫持”。7. 給不同使用場景的最終建議如果你只是做一個Spring Boot的學習項目Maven 3.8.8加上阿里云鏡像十分鐘內(nèi)就能搞定環(huán)境用起來完全夠。如果你是企業(yè)開發(fā)或老項目維護請多留意JDK版本和插件版本盡量不要在Maven本身做激進升級。如果你是長期從事Java開發(fā)的工程師我強烈建議你好好讀一遍settings.xml里的注釋那些英文注釋雖然啰嗦但一個字一個字看完你對Maven的理解會上一個臺階。最后分享一下我現(xiàn)在的工作習慣在每臺開發(fā)機上我會把Maven的settings.xml放在一個獨立目錄比如~/maven-conf/settings.xml然后通過MAVEN_HOME和IDE配置同時指向它。這樣不管我在哪臺機器、哪個項目上工作行為都保持一致。配置里面除了本地倉庫、鏡像我還會把offline設(shè)置為false因為我不希望Maven在倉庫緩存崩潰時自動進入離線狀態(tài)那會讓后續(xù)排查變成“大海撈針”。Maven 3.8.8的安裝只是起點真正要花時間去琢磨的是你怎么通過依賴管理把項目從“能跑”變成“能長期維護”。環(huán)境搭好后找一個小項目親手跑幾遍clean install把下載、編譯、打包、安裝的日志從頭到尾看一遍你會收獲比任何教程都多的實踐經(jīng)驗。