Windows环境下Maven安装与使用这个话题看起来基础但实际操作中坑不少。我见过太多人在这一步卡住明明照着教程一步步来最后mvn -v就是报错。问题往往出在一些细节上比如JDK版本不匹配、环境变量没生效、镜像仓库没配好。这篇文章我就把自己踩过的坑、验证过的方法完整梳理一遍从零开始带你装好Maven并且真正用起来。1. 内容整体设计与思路拆解1.1 为什么Windows上装Maven比看起来更讲究Maven本质上是一个项目管理和构建自动化工具核心能力是依赖管理和项目生命周期管理。在Java生态里它几乎是标配。但Windows环境和Linux环境有个显著差异Windows没有统一的包管理机制环境变量配置也更容易出错路径分隔符、权限问题、编码问题都比Linux下更频繁出现。所以Windows下装Maven要解决的问题不只是“下载一个压缩包解压”这么简单至少包含下面几个层面。第一是基础运行环境的搭建。Maven本身是Java写的工具必须先有JDK才能运行。JDK版本和Maven版本之间存在兼容矩阵选错版本会出现很莫名的问题。第二是本体安装和路径规划。Maven解压到哪个目录、本地仓库放在哪、配置文件放在哪这些路径如果规划不好后续项目多了会很痛苦。第三是配置文件定制。Maven的settings.xml不只是简单改个仓库地址本地仓库位置、镜像、代理、Profile、插件版本锁定等都需要在安装阶段就打好基础。第四是命令行环境验证。环境变量配置好后要确保mvn命令在任何目录都能直接运行并且能正确识别到JDK。我最初在自己电脑上配置Maven时第一次就遇到了JDK版本和Maven版本不兼容的问题。当时下载的是Maven 3.8.x配的JDK 1.7结果运行mvn -v直接提示UnsupportedClassVersionError。后来统一升到JDK 1.8以上才正常。现在Maven 3.9.x要求JDK 1.8及以上部分新功能需要JDK 11以上安装前一定要先确认好版本对应关系。1.2 选择适合Windows环境的Maven版本当前主流的Maven版本为3.6.x和3.9.x。对于新项目我建议直接选择3.9.x系列它是目前最新的稳定版本支持JDK 8到JDK 21兼容性最好。如果你还在维护老项目或者团队内部有固定版本要求那3.6.3也是一个很好的选择长期稳定插件生态成熟。从官方下载页面可以看到Windows下有两个主要压缩包格式apache-maven-3.9.x-bin.zip和apache-maven-3.9.x-src.zip。普通开发者只需要下载bin.zip这个是编译好的可直接运行的二进制版本。Souce包一般只有需要对Maven本身做二次开发的极少数人才需要我们根本用不到。下载后不要直接把zip包解压到带有中文、空格或特殊字符的路径下。这个问题我踩过解压到D:\工具\Apache Maven这种路径后在某些终端环境下会出现路径无法识别的现象尤其是配合一些CI工具或者脚本执行时。规范的做法是把Maven放到一个纯英文路径比如D:\dev\apache-maven-3.9.9同时把JDK也放到相邻的目录比如D:\dev\jdk-17这样后续管理起来一目了然。1.3 配置前先理清目录规划目录规划是很多人忽略的一点但它直接决定了后续使用的舒适度。我在实际项目中采用过多种目录布局最后稳定下来的方案很清晰简洁Maven主目录D:\dev\apache-maven-3.9.9JDK目录D:\dev\jdk-17本地仓库目录D:\dev\repository项目工作目录D:\workspace这套规划的好处是三块职责完全分开。Maven程序本身和本地仓库分离好处是升级Maven时不需要迁移依赖包因为依赖已经下载到本地仓库中了。JDK独立存放方便后续切换或升级。项目工作区单独一个盘符下的目录方便统一管理和备份。尤其要强调本地仓库规划。Maven默认会把依赖下载到用户目录下的.m2\repository。如果C盘空间紧张或者系统重装时容易丢失最好一开始就改到其他位置。这个配置是在settings.xml中通过localRepository标签指定的。2. 核心细节解析与实操要点2.1 JDK配置是Maven一切的基础Maven本身不会去检查JDK的安装方式它只是读取JAVA_HOME环境变量。所以想让Maven正常运行JAVA_HOME的配置必须正确。在Windows上配置JAVA_HOME要注意不要配置成C:\Program Files\Java\jdk-17\bin而是配置到JDK的根目录也就是不包含bin的那一层。Maven在执行时会自动拼接bin目录下的可执行文件。我见过很多初学者把JAVA_HOME配置到了bin目录结果mvn -v提示找不到Java环境。配置JAVA_HOME的步骤如下右键“此电脑”选择“属性”。点击“高级系统设置”。点击“环境变量”。在系统变量区域点击“新建”。变量名填入JAVA_HOME变量值填入你的JDK安装根目录例如D:\dev\jdk-17。找到Path变量点击编辑新增一条%JAVA_HOME%\bin。这里有个细节在Windows 10以上系统Path变量编辑界面变成了列表形式逐条新增即可。不要删掉原有的任何路径否则可能影响系统其他程序运行。配置完成后打开一个新的命令行窗口一定要新开一个因为旧的命令行窗口不会刷新环境变量输入java -version验证。如果输出正确显示的版本信息就说明JDK部分没有问题。2.2 Maven安装三步走Maven的安装过程非常简单概括起来就三步解压、配置环境变量、验证。解压时我建议把zip包内的整个目录直接拷贝到目标位置不要用“剪切到”或者“右键解压到当前文件夹”再手工改名容易产生路径错位问题。解压完成后进入目录检查一下确认能看到bin、conf、lib等子目录。配置环境变量在系统变量中新建一个变量名MAVEN_HOME变量值填Maven的解压目录例如D:\dev\apache-maven-3.9.9。然后编辑Path变量新增一条%MAVEN_HOME%\bin。验证安装新开一个命令行窗口输入mvn -v。正常输出类似下面这样Apache Maven 3.9.9 (8e3f3c1f1c0e3d0e6f0c6d0e5b0a9e2) Maven home: D:\dev\apache-maven-3.9.9 Java version: 17.0.8, vendor: Oracle Corporation, runtime: D:\dev\jdk-17 Default locale: zh_CN, platform encoding: UTF-8如果看到这样的输出说明安装成功。如果提示“不是内部或外部命令”优先检查Path变量是否配置正确然后重新开一个命令行窗口。如果UnsupportedClassVersionError说明JDK版本和Maven版本不匹配升级JDK即可。2.3 settings.xml配置是Maven的灵魂Maven安装好之后的默认配置能跑但难用。真正让Maven好用起来的是settings.xml文件的几处关键配置。settings.xml位于Maven主目录下的conf文件夹中。全局配置修改的是D:\dev\apache-maven-3.9.9\conf\settings.xml。除此之外还有用户级配置位置在用户目录下的.m2\settings.xml。用户级的配置优先级高于全局配置。实际使用中我更推荐直接修改全局配置文件这样团队协作时大家能保持一致的配置。个人开发机器上两种方式都可以。需要修改的核心项有三个。第一个是本地仓库位置。找到localRepository注释块改为localRepositoryD:/dev/repository/localRepository。注意Windows路径用的是正斜杠或双反斜杠像D:\\dev\\repository这种写法也是可以的但直接用正斜杠最不容易出问题。第二个是镜像配置。Maven中央仓库的下载速度在国内很多时候不尽如人意。配置阿里云镜像仓库是提速的最直接手段。在mirrors标签中添加一个mirrormirror idaliyunmaven/id mirrorOfcentral/mirrorOf namealiyun maven/name urlhttps://maven.aliyun.com/repository/public/url /mirror这里mirrorOf的值central表示只覆盖中央仓库。如果希望所有仓库请求都走这个镜像可以配置为*不过我建议保持central以免影响某些私有仓库的正常访问。第三个是JDK版本锁定。在profiles标签中添加一个Profile强制Maven使用JDK 17进行编译profile idjdk-17/id activation activeByDefaulttrue/activeByDefault /activation properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties /profile项目编码设置成UTF-8这一点很重要。Windows系统默认编码是GBK如果项目里有中文字符不设置UTF-8的话编译时会出现乱码或编码错误。2.4 环境变量配置的常见注意点环境变量配置不复杂但有几个细节值得多啰嗦几句。第一不要配置用户变量和系统变量两套只配置系统变量一套就够了。如果用户变量里曾经配置过旧的JAVA_HOME或MAVEN_HOME会覆盖系统环境的配置导致新配置不生效。第二Path地址的排列顺序有一定影响。如果电脑上同时装有多个JDK版本Path中靠前的Java相关路径会被优先匹配到。我建议在Path中把关键条目都排在前面以免被某些软件自动添加的其他Java路径挤到后面去。第三配置完成后一定要重新打开一个命令行窗口。很多人配置完环境变量后在旧窗口里执行mvn -v发现不生效就以为是配置错了。其实只是因为环境变量的读取是发生在进程启动时旧窗口的环境变量快照已经固定了。3. 实操过程与核心环节实现3.1 从零到一完整搭建实例我以一套完整的实例来演示从下载到项目跑通把每个环节都走一遍。假设要搭建的环境是JDK 17 Maven 3.9.9本地仓库放在D盘项目工作目录为D:\workspace。第一步检查JDK是否已安装。打开命令行输入java -version。如果提示找不到命令先去安装JDK。我推荐直接安装JDK 17长期支持版本。JDK安装完成后配置JAVA_HOME环境变量。第二步下载Maven。访问Maven官方仓库的下载页面选择apache-maven-3.9.9-bin.zip下载完成后解压到D:\dev\apache-maven-3.9.9。第三步配置环境变量。按照前面说的方法新建MAVEN_HOME修改Path新开命令行执行验证。第四步修改settings.xml。打开D:\dev\apache-maven-3.9.9\conf\settings.xml依次完成本地仓库、镜像、JDK版本Profile三处修改。第五步创建测试项目。在命令行中执行以下命令cd /d D:\workspace mvn archetype:generate -DgroupIdcom.demo -DartifactIddemo-app -DarchetypeArtifactIdmaven-archetype-quickstart -DinteractiveModefalse第一次执行这个命令时Maven会下载大量插件和依赖耗时较长。看到BUILD SUCCESS就说明项目骨架创建成功。第六步编译项目。进入项目目录执行mvn compile。命令行输出会显示编译过程最终出现BUILD SUCCESS后就可以使用Maven了。过程中如果依赖下载很慢多半是镜像没有配置正确。可以打开本地仓库目录看一下确认生成的jar包是否有部分文件大小为零或download包如果有说明下载失败需要检查网络或镜像配置。3.2 常用命令体系与使用场景项目创建好之后就需要熟练使用Maven的各种常用命令了。我整理了一个使用频率较高的命令清单。mvn clean是清理命令删除target目录下的所有编译产物。这个命令适合在重新打包前执行保证没有旧产物残留。mvn compile是编译命令把src/main/java下的Java文件编译成class文件到target/classes目录只编译主代码不处理测试代码。mvn test是执行测试命令会先编译主代码再编译测试代码然后运行test目录下所有测试用例。遇到单元测试失败时会构建失败默认行为如此。mvn package是打包命令会执行编译和测试然后把最终产物打包成jar包或war包存放在target目录下。打包Spring Boot项目时得到的是可执行jar包普通Java项目得到的是普通jar包。mvn install是安装命令把打包产物安装到本地仓库中。这样本地其他项目通过依赖坐标就能引用到该构建产物。mvn clean install是最常用的组合命令先清理再打包安装一条命令完成完整流程。在Windows命令行中可以使用mvn clean install -DskipTests跳过测试执行。也有mvn clean install -Dmaven.test.skiptrue这种跳过测试编译和执行的写法。两者区别在于后者跳过测试代码编译前者只是跳过执行阶段。实际开发中还有一个高频命令mvn dependency:tree用于查看项目的依赖树排查依赖冲突非常好用。找出某个依赖是从哪里引入的比在IDE里检查依赖关系更方便。3.3 实际项目中的依赖管理配置随便用个简单的Spring Boot项目来举个例子演示依赖管理在Maven中是怎么配置的。project xmlnshttp://maven.apache.org/POM/4.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd modelVersion4.0.0/modelVersion groupIdcom.demo/groupId artifactIddemo-app/artifactId version1.0.0/version packagingjar/packaging properties maven.compiler.source17/maven.compiler.source maven.compiler.target17/maven.compiler.target project.build.sourceEncodingUTF-8/project.build.sourceEncoding /properties dependencies dependency groupIdorg.apache.commons/groupId artifactIdcommons-lang3/artifactId version3.14.0/version /dependency /dependencies /project这个pom.xml通过groupId、artifactId、version三个坐标唯一定位一个依赖。Maven解析后会从配置的镜像仓库下载对应jar包到本地仓库编译时直接引用。依赖的scope属性经常需要用到它控制依赖的作用范围。compile是默认作用域打包时包含在jar中适合commons-lang3这类运行时需要的依赖。provided作用域在打war包时不打包进去因为Servlet容器已经提供了相关类如果打包进去反而会和容器的类冲突。test作用域只在测试阶段有效生产包中不包含适合JUnit这类只在测试时使用的依赖。3.4 IDEA中的Maven集成技巧命令行能用起来IDE环境的集成也不能落下。最常用的开发环境是IntelliJ IDEA它的Maven集成做得很完善关键配置说三个。配置Maven主目录和用户settings文件。打开IDEA进入File - Settings - Build, Execution, Deployment - Build Tools - Maven。在Maven home path处选择D:\dev\apache-maven-3.9.9在User settings file处选择D:\dev\apache-maven-3.9.9\conf\settings.xmlLocal repository会自动识别为settings.xml里配置的路径。这一步做了之后IDEA内的Maven就会使用命令行一致的配置。配置JDK版本。在Settings - Build, Execution, Deployment - Build Tools - Maven - Importing中设置JDK for importer为JDK 17。在Settings - Build, Execution, Deployment - Compiler - Java Compiler中确保Project bytecode version选择17。这一步经常被忽略IDEA默认可能会用JAVA_HOME配置的JDK版本如果pom.xml中指定了不同的编译版本也会以pom.xml为准。配置自动导入。IDEA中首次打开Maven项目时右下角会弹出Auto Import的提示点击Enable Auto-Import。这样pom.xml修改后IDEA会自动刷新依赖不需要手动右键Maven再Reload Project。IDEA右侧有一个Maven工具栏面板可以可视化地执行clean、install、package等命令。社区版和旗舰版都有这个功能面板使用体验很好日常开发直接点击即可不需要切换到命令行执行。4. 常见问题与排查技巧实录4.1 高频报错速查表整理了以下几个我在Windows环境下反复遇到的问题做成速查表方便随时对照。现象可能原因解决方案mvn不是内部或外部命令MAVEN_HOME未配置或Path不完整检查MAVEN_HOME和Path配置重新打开命令行java不是内部或外部命令JAVA_HOME未配置或Path不完整检查JDK安装路径和JAVA_HOME配置UnsupportedClassVersionErrorJDK版本低于Maven要求升级JDK到合适版本建议JDK 17编译时中文乱码项目编码未设置为UTF-8在pom.xml或settings.xml中配置UTF-8编码依赖下载总是超时没有镜像或镜像地址错误配置阿里云镜像检查网络连通性依赖冲突异常多个版本jar包共存使用dependency:tree排查冲突找不到本地仓库依赖localRepository配置后未生效检查settings.xml存放位置和语法正确性IDEA识别不了Maven项目主目录配置错误在IDEA的Maven设置中重新指定主目录和settings文件4.2 依赖下载失败的深度排查依赖下载失败是Maven使用中遇到概率最高的问题特别是刚配置好Maven的第一次使用。下载失败时的现象是命令行输出一堆红色ERROR信息常见的有Could not transfer artifact和Failed to collect dependencies。排查思路按优先级排列如下。第一步检查网络连通性。在浏览器中直接访问仓库地址比如阿里云镜像的公网地址如果浏览器能访问但Maven下载失败大概率是Maven配置问题了。第二步检查镜像配置是否正确。settings.xml中mirror的url地址需要是镜像站点的真实地址配置成错误的地址就会报404或连接超时。我在早年就踩过把https写成了http导致下载直接被拒绝的坑。第三步检查本地仓库中是否有残留的.lastUpdated文件。Maven下载失败后不会自动重试因为本地仓库的lastUpdated文件记录了失败的时间戳短时间内的重试会被直接拒绝。处理方式是删除本地仓库中对应的lastUpdated文件或者使用mvn clean install -U强制更新。-U参数作用是强制刷新所有依赖的最新版本快照。第四步检查证书问题。如果公司内网使用了一些代理网关HTTPS证书可能被替换报PKIX path building failed错误。这时可以尝试将镜像地址切换为http版本或者把镜像仓库的证书导入到JRE的cacerts信任库中。不过这个坑在个人开发者中相对少见多见于企业内部环境。4.3 多JDK环境切换的实战技巧很多开发者电脑上不会只有一个JDK版本。项目A需要JDK 8项目B需要JDK 17频繁切换是常态。Windows下切换JDK环境有几种方案我最推荐使用Maven的Toolchain机制。Maven Toolchain是在settings.xml中定义一个或一组JDK路径pom.xml中通过指定toolchain的version来使用特定JDK。配置方法如下toolchains toolchain typejdk/type provides version17/version vendororacle/vendor /provides configuration jdkHomeD:/dev/jdk-17/jdkHome /configuration /toolchain /toolchains这样Maven在构建时可以根据pom.xml中的maven.compiler.source标签自动选择匹配的JDK来编译开发者不需要手动切换JAVA_HOME。Toolchain在处理需要不同JDK版本构建多个项目时特别好用尤其是在CI持续集成环境中批量构建的场景。小规模切换JDK时我习惯用一个简易的批处理脚本来切换JAVA_HOME。新建一个switch-jdk.bat文件echo off setx JAVA_HOME D:\dev\jdk-17 /M set Path%JAVA_HOME%\bin;%Path% echo Switched to JDK 17 cmd /k cd /d D:\workspace执行这个脚本后当前命令行窗口就会立即切换到新的JDK环境。不过setx命令修改的是系统环境变量需要用管理员权限执行否则权限不足会报错。这个脚本适合临时切换长期配置还是建议用Toolchain或者IDEA的项目级SDK设置。IDEA的Project Structure中可以单独为每个Project指定SDK版本结合Maven的pom.xml编译版本配置开发时几乎感受不到切换JDK的痛苦。4.4 结合实战一个常见依赖冲突的排查过程拿到一个实际场景来演示排查思路。假设项目引入了A模块A模块依赖了commons-io 2.4版本。项目又直接引入了commons-io 2.11版本。Maven默认采用最近定义优先的依赖仲裁策略最终生效版本取决于pom.xml中的声明顺序和后出现的依赖。Maven仲裁规则是先声明优先也就是说相同深度的依赖靠前声明的胜出。如果A模块在后面的第三方依赖中引入了低版本的commons-io而你的项目前面有高版本声明那Maven会保留高版本并排除低版本传递依赖。最常见的冲突问题是项目直接声明的B模块传递依赖了C模块的1.0版本另一个模块D又传递依赖了C模块的2.0版本。这时运行会抛出像NoSuchMethodError或ClassNotFoundException这样的异常。排查命令就是mvn dependency:tree -Dverbose -Dincludescommons-io这个命令会输出所有关于commons-io的依赖路径从哪里引入的每一条都显示得清清楚楚。找到冲突后在pom.xml中通过exclusion标签排除不需要的版本或者通过dependencyManagement统一版本号。dependency groupIdcom.example/groupId artifactIdmodule-a/artifactId version1.0.0/version exclusions exclusion groupIdcommons-io/groupId artifactIdcommons-io/artifactId /exclusion /exclusions /dependency这是Maven使用中最常见的实际排错场景能熟练掌握dependency:tree这个命令就基本掌握了依赖冲突排查的核心方法。5. 进阶使用技巧与个性化配置5.1 利用Mirror与Proxy提升下载体验除了配置公共镜像外如果有自己的私有仓库比如公司内部的Nexus或ArtifactoryMirror的配置就更重要了。配置mirrorOf时可以支持通配符如external:*表示匹配除了本地文件系统仓库以外的所有仓库*表示匹配所有仓库。私有仓库的场景下建议配置为mirror idnexus/id mirrorOf*/mirrorOf nameNexus Repository/name urlhttp://internal-nexus.example.com/repository/maven-public//url /mirror注意这里的url需要是Nexus的公共组地址这样所有外部依赖请求都会先经过Nexus缓存。Nexus没有缓存的内容会从上游源拉取后续再请求时就直接走缓存了极大提升下载效率。部分企业网络环境需要代理才能访问外网这时需要在settings.xml中配置Proxy信息proxies proxy idhttp-proxy/id activetrue/active protocolhttp/protocol hostproxy.example.com/host port8080/port usernameuser/username passwordpass/password nonProxyHostslocalhost|*.example.com/nonProxyHosts /proxy /proxies配置代理时注意nonProxyHosts的写法用|分隔多个拒绝走代理的主机名。如果代理本身不可用Maven会把所有请求都尝试发到代理上造成大量连接超时。排查时先确认代理服务器是否正常再确认账号密码是否正确。5.2 使用Maven Wrapper保障项目构建一致性Maven Wrapper是官方推荐的项目级Maven版本管理方案。它在项目中添加一个mvnw脚本使用这个脚本构建时会自动下载并使用项目指定的Maven版本完全不受本机Maven版本的影响。这在多人协作时非常有用可以保证团队成员无论在哪个环境构建所用Maven版本完全一致。在项目根目录执行mvn wrapper:wrapper -Dmaven3.9.9执行完成后目录下会多出mvnw、mvnw.cmd和.mvn/wrapper/目录。Windows环境下后续构建时使用mvnw.cmd命令即可。Maven Wrapper会读取.mvn/wrapper/maven-wrapper.properties中指定的版本号并自动下载对应版本的Maven。团队项目里推进Maven Wrapper是个很好的实践。Windows环境下我遇到过团队成员本机Maven版本不统一导致的构建行为差异问题引入Wrapper后这类问题几乎绝迹。命令行执行mvnw.cmd clean install和mvn clean install的效果完全一致但底层Maven版本被固定了。5.3 为Maven配置自定义生命周期插件Maven的构建过程本质上是多个插件的按序执行。日常项目中最常用的插件包括maven-compiler-plugin、maven-surefire-plugin、maven-jar-plugin等。在实际开发中经常需要扩展一些自定义能力比如打包时生成额外文件、执行代码检查、生成API文档。以生成jar包可执行文件为例需要配置maven-jar-plugin指定Main-Classbuild plugins plugin groupIdorg.apache.maven.plugins/groupId artifactIdmaven-jar-plugin/artifactId version3.4.1/version configuration archive manifest mainClasscom.demo.Main/mainClass /manifest /archive /configuration /plugin /plugins /build配置后执行mvn package生成的jar包直接通过java -jar命令就能启动。如果项目依赖了第三方库还需要配合maven-assembly-plugin或spring-boot-maven-plugin来生成包含所有依赖的可执行jar包。插件配置中版本号的锁定同样重要。不指定插件版本会使用Maven默认绑定版本这在不同Maven版本下可能不同造成构建行为不一致。我建议在pom.xml中通过pluginManagement统一所有插件版本这样团队内构建效果完全一致。6. 一些经验随笔6.1 Windows环境下绕过导致构建失败的特殊字符问题在Windows的cmd和PowerShell中执行Maven命令时某些特殊字符会被解析器错误处理。最典型的是在命令行中使用-D参数传递包含逗号、分号、括号等值的场景。例如-Dincludecom.demo.*在某些终端环境下星号会被自动展开导致传递参数错误。处理办法是用引号包住整个参数比如-Dincludecom.demo.*。PowerShell中还要注意-D参数名中大写字母的传递可能被某些版本误解析。另一个高频坑是路径中包含符号的时候。Windows的cmd把当成命令分隔符如果项目路径或参数中包含这个符号需要转义或用引号包裹。仓库路径中存在时建议直接改用不含特殊字符的路径省去后续无穷无尽的问题。6.2 Maven命令行编码问题的根因分析Windows下Maven编译时中文乱码根因在于Windows系统默认使用GBK编码而Maven和Java编译器默认读取UTF-8编写的源码文件。当源码中包含中文注释或中文字符串时编译器用GBK去解码UTF-8内容就会出现乱码甚至编译失败。解决方案就是前面提到过的在pom.xml的properties或settings.xml的profile属性中统一设置project.build.sourceEncodingUTF-8。同时还要注意如果是在cmd窗口中直接执行mvn命令窗口本身也需要执行chcp 65001切换代码页才能正确显示中文输出。PowerShell窗口一般默认支持UTF-8显示但cmd就需要额外设置这一步。IDEA环境下还需要确保File Encoding设置中全部选项设置为UTF-8。在Settings - Editor - File Encodings中将Global Encoding、Project Encoding、Default encoding for properties files都设置为UTF-8。这三处设置不一致会导致同一个项目在不同环境下编译出现编码问题。把这些编码坑在安装Maven阶段就提前规避掉比出现问题后一个个排查要省心得多。我常在配置完Maven后第一件事就是创建一个带中文输出的测试类跑一遍编译确保整个链路编码一致。6.3 从安装到应用的最佳实践路径Maven安装使用不是一蹴而就的事需要在实际项目中不断磨合。初次接触Maven的同学我建议按照这个顺序逐步掌握先搭建最小环境把JDK和Maven装好命令行能执行mvn -v。然后找一个现有项目导入IDEA熟悉Maven工具栏的操作。接着自己创建一个最简单的Java项目练习clean、compile、package、install这些基础命令。然后逐步引入Spring Boot、MyBatis等框架理解依赖管理与传递依赖的机制。最后再研究冲突排查、插件扩展、多环境配置等进阶内容。Windows下使用Maven关键是基础配置要一次做对。环境变量、settings.xml、编码设置这三项配置得越规范后期使用越顺畅。很多过来人觉得Maven难用仔细一问几乎都是前期配置不规范导致的。从我自己的经验来看Maven的报错信息虽然看起来复杂但基本都可以追溯到配置或依赖关系这两个根因。掌握Maven的核心不在于记住所有命令而在于理解它“项目生命周期依赖管理”这个核心设计理念。阅读官方文档是个不错的学习途径配合实际项目练习上手会非常快。
