企业官网建设流程全解析

Java项目里打交道最多的工具，除了JDK大概就是Maven了。我刚入行那会儿，装Maven这件事真的折磨了我一整个下午——官网下载慢到怀疑人生，好不容易下完解压完，一敲mvn -v直接提示找不到命令，后来配好了环境变量，进IDEA又发现项目所有依赖都在报错，折腾到晚上才搞清楚是settings.xml里的镜像没配。回头再看，Maven的安装和配置其实半小时就能搞定，大部分时间都浪费在“不知道每一步在干什么”上。

这篇文章就是来填这个坑的。我会从Maven到底解决什么问题讲起，到下载安装、环境变量、settings.xml配置、IDEA集成，最后整理几个新手几乎必踩的报错和完整排查思路。不管你是刚接触Maven的Java小白，还是被环境问题折磨的老手，照着做就能省下那一下午。

1. 为什么所有Java项目都绕不开Maven

很多人第一次听到Maven，是从同事嘴里蹦出的“你用Maven拉一下依赖”“mvn clean package跑一下”开始的。但Maven到底是什么？如果你只知道它是“下载jar包的工具”，那后面遇到问题会很被动。这里我用比较通俗的方式拆一遍，顺便解释几个安装配置时会反复遇到的概念。

1.1 Maven到底帮你做了什么

Maven的核心能力可以归纳成三件事：依赖管理、标准构建、项目规范。

依赖管理就是帮你自动下载和管理第三方jar包。你自己写项目肯定要用到各种开源库，比如Spring、MySQL驱动、日志组件。没有Maven的时候，你得去官网一个个下载jar包，塞进lib目录，还要自己操心版本兼容，换版本就要手动删旧包。有了Maven之后，你只需要在pom.xml里写一段XML声明依赖坐标，比如com.mysql:mysql-connector-j:8.4.0，Maven就会自己跑去仓库把对应jar包拉下来，放到本地一个统一的地方，所有项目共用。

标准构建就更好理解了。打包、编译、跑测试、部署，这些操作如果你手动做，每换一台电脑都要重新教同事一遍。Maven把一套标准流程固化成了生命周期命令：mvn clean清理、mvn compile编译、mvn test跑测试、mvn package打包、mvn install安装到本地仓库。所有Java项目都遵循同一套流程，换人接手成本极低。

项目规范则是Maven强制约定的目录结构：源码放src/main/java，资源文件放src/main/resources，测试代码放src/test/java。这套约定看起来死板，但避免了“你的项目文件名叫a，我的叫b”这种混乱。说白了，Maven就是替你把工程管理里最繁琐、最容易出错的重复劳动自动化了。

1.2 三个仓库层级和阿里云镜像的实际意义

配置Maven时你一定会遇到三个词：本地仓库、中央仓库、镜像仓库。搞懂它们，后面配settings.xml就有依据了。

• 本地仓库（Local Repository）：默认在~/.m2/repository目录，是jar包在你电脑上的存放位置。Maven先从这找，找不到才去远程下载。
• 中央仓库（Central Repository）：Maven官方维护的公共仓库，存放了几乎所有开源Java库，但服务器在国外，国内直接访问速度很感人。
• 镜像仓库（Mirror Repository）：就是中央仓库的“国内加速节点”。比如阿里云的Maven仓库，内容会同步中央仓库，但下载速度快几个数量级。

我见过很多人卡在这：依赖报红、项目启动超级慢，都是因为一直在连中央仓库，一个几十MB的大包要下十分钟。把镜像换成阿里云之后，同样的包几秒钟就完了。所以“配置阿里云仓库”不是可选项，基本是国内容器必备操作。具体配置方法我在第3章会给出可直接抄的完整XML。

1.3 有哪些可行的替代方案

安装Maven之前，顺便提一下市面上常见的几个选择，免得你听别人聊起时一头雾水。

• Gradle：目前Android开发和部分新Spring项目的默认构建工具，配置用Groovy或Kotlin DSL，语法更简洁，构建速度也常比Maven快。但Maven的生态和普及度仍然最高，老项目和大多数企业内部项目还是Maven为主。
• IDEA自带的Bundled Maven：新版IDEA内置了一个Maven，不需要安装也能跑，但版本通常较老，而且全局配置文件没法灵活自定义，所以还是推荐单独装一个。
• Maven wrapper：类似Maven版的“便携JDK”，项目里放一个mvnw脚本，能自动下载指定版本Maven，避免多人开发时版本不一致。属于进阶玩法，新手可以等熟悉之后再了解。

结论很直接：如果你是Java开发者，Maven是逃不掉的第一课，老老实实装一个独立Maven，配好仓库和IDEA集成，一劳永逸。

2. 下载安装与版本选择的那些坑

先说一句总结性经验：Maven安装失败，九成出在环境变量上，剩下的出在版本不匹配上。这一章直接从下载开始，把Windows和Mac两条线路都走一遍。

2.1 官网下载与版本选型

Maven官网是maven.apache.org，首页往下找Downloads链接，进去会看到镜像地址列表。推荐直接用Apache官方位于dlcdn的下载链接，或者用国内镜像下载站（比如阿里云镜像站mirrors.aliyun.com/apache/maven/）下binary zip包，速度快很多。

版本选择是个容易踩坑的地方。目前主流的稳定大版本是3.8.x和3.9.x，我推荐大家直接用3.9.9（或3.9系列任意最新版），它支持JDK8到JDK21，兼容面覆盖绝大多数场景。如果有老项目锁定了低版本，那装3.6.3也是可以的，但3.6.3在JDK17以上的环境里会有些隐患，所以新环境优先3.9.x。至于网上偶尔看到的“Maven 3.7下载”，其实Apache根本没有正式发布过3.7这个版本，别在第三方网站随便下文件，小心下到被篡改的压缩包。

下载文件选择apache-maven-3.9.9-bin.zip即可，-src.zip是源码包，普通用户用不到。All right，解压到哪里也有讲究：目录路径不要带中文，不要有空格，比如D:\Maven\apache-maven-3.9.9就很稳妥。放在C:\Program Files下面虽然也能跑，但路径里的空格偶尔会让你在脚本处理时遇到莫名其妙的问题，完全没必要赌这个。

2.2 Windows环境变量配置详解

解压完成后，真正的重点来了——配置环境变量。

右键“此电脑” → 属性 → 高级系统设置 → 环境变量。这里要新增两个东西：

1. 新建系统变量MAVEN_HOME，变量值填你的解压路径，比如D:\Maven\apache-maven-3.9.9。
2. 在系统变量Path中追加%MAVEN_HOME%\bin。

注意是追加，不是覆盖。Path里面已经有其他软件的路径，千万不要清空重写，否则连Java命令都会一起失效。追加的时候如果你在图形界面里编辑，点“新建”输入一行%MAVEN_HOME%\bin就行；如果是在老版本Windows那种一行一个路径的界面，就在原有值最后加分号再接进去。

为什么要单独建MAVEN_HOME而不是直接写全路径到Path？因为Maven未来升级或者换路径时，你只需改MAVEN_HOME一个地方，Path里的引用不用动。这是管理软件环境的标准做法，Linux下配置JAVA_HOME也是同一个道理。

配置完成，开一个新的命令行窗口（务必新开，旧窗口读不到刚改的环境变量），执行：

mvn -v

正常输出里包含Maven home、Java version等信息，比如：

Apache Maven 3.9.9 (8e3b7be9d36f6a8e0a7c1e2b3c4d5e6f7a8b9c0d) Maven home: D:\Maven\apache-maven-3.9.9 Java version: 1.8.0_411, vendor: Oracle Corporation

如果提示“不是内部或外部命令”，依次排查：环境变量是否改在了用户变量而不是系统变量（两个都可，但系统变量所有用户公用，推荐系统变量）；Path追加是否生效；解压目录下的bin目录里是否有mvn.cmd文件。

2.3 在Mac和Linux上配置

Mac上配置稍微优雅一点。下载好的apache-maven-3.9.9-bin.tar.gz解压后，建议放到/usr/local/maven目录下，然后在~/.zshrc（Catalina以后默认shell是zsh；如果你是bash，就是~/.bash_profile）里加两行：

export MAVEN_HOME=/usr/local/maven/apache-maven-3.9.9 export PATH=$MAVEN_HOME/bin:$PATH

保存后用source ~/.zshrc刷新生效，再跑mvn -v验证。

Linux也类似，把目录换成/opt/maven即可。无论哪种系统，前提都是你的JAVA_HOME已经配好、java -version能正常输出。Maven运行完全依赖JDK，所以装Maven之前务必先把JDK装好，版本上JDK8或JDK17都行，但要注意Maven 3.9要求在JDK8以上。

2.4 老系统与低版本JDK的兼容问题

如果你手上是Windows 7这类老系统，想装Maven也不是不行，但有讲究。Windows 7官方最多支持到JDK8，所以Maven版本最好选3.6.3或3.8.8。3.8.8是我测过在Win7+JDK8环境里比较稳的版本，3.9.x虽然最低要求也是JDK8，但在老系统上偶发过SSL证书相关的仓库连接问题，没必要冒险。

另外，Win7上安装时右键解压软件可能不识别zip大包，建议用7-Zip解压。环境变量界面和Win10不太一样，编辑Path时看清楚变量名，别改串到其他系统变量。这种老环境装完别急着跑大型项目，先用mvn -v验证，再用一个空项目的mvn clean compile跑通流程，确认基础链路健康，再往IDEA里集成。

3. settings.xml：配置一次，受益所有项目

装好Maven只是第一步，真正决定你用起来爽不爽的，是settings.xml这个文件。很多教程最后都让你去改它，但没讲清楚为什么。这章把settings.xml里的关键配置挨个拆开，并给出一份可以直接复制的完整版。

3.1 本地仓库路径为什么不要默认值

Maven的本地仓库默认在C:\Users\你的用户名\.m2\repository，对Windows用户来说这是C盘。随着项目越来越多，本地仓库体积轻松上到几个GB，全部堆在C盘，系统盘的可用空间肉眼可见地掉。

所以装完Maven第一件事，把本地仓库挪到别的盘。修改方式有两处：

1. 修改Maven自带的conf/settings.xml，即全局配置，所有用户都生效。
2. 在你自己的~/.m2目录下新建一个settings.xml，只对当前用户生效。

推荐改全局的。用编辑器打开D:\Maven\apache-maven-3.9.9\conf\settings.xml，找到<localRepository>节点。注意原文件里这个节点是被注释掉的，把它解注释并将路径改成你的目标路径：

<localRepository>D:/MavenRepo</localRepository>

路径分隔符用/还是\都能识别，但建议统一用/，避免转义问题。

3.2 阿里云镜像与多镜像配置

下载依赖慢是国内容器最大的痛点。settings.xml里的<mirrors>节点就是为这个准备的。配置镜像的逻辑很简单：当Maven需要从中央仓库拉取东西时，会先看mirrors列表，把请求转发给匹配的镜像地址。

阿里云公共仓库的地址是https://maven.aliyun.com/repository/public，这个地址聚合了中央仓库和常用的开源仓库。配置方法是在<mirrors>标签内加一个<mirror>：

<mirror> <id>aliyunmaven</id> <name>Aliyun Public</name> <url>https://maven.aliyun.com/repository/public</url> <mirrorOf>central</mirrorOf> </mirror>

这里的mirrorOf字段很关键。填central表示只拦截中央仓库的请求，其他仓库不受影响；填*表示拦截所有仓库请求，这样会导致自定义私有仓库也被转发到阿里云，不建议。如果你公司有私有Nexus仓库，正确做法是mirrorOf设为central,jcenter这种指定集合，让外部依赖走阿里云，私有依赖走公司仓库。

想要配置多个镜像，就在<mirrors>下面并列多个<mirror>节点。Maven会按声明顺序依次尝试，如果第一个镜像请求失败，会继续尝试下一个。这种配置在应对某个镜像临时故障时很有用，比如再加一个华为云镜像或腾讯云镜像作为备胎：

<mirror> <id>huaweicloud</id> <name>Huawei Cloud</name> <url>https://repo.huaweicloud.com/repository/maven/</url> <mirrorOf>central</mirrorOf> </mirror>

3.3 JDK编译级别与profile

每次新建项目都要手动把JDK版本从默认的1.5改成1.8或17，这事烦不烦？烦。settings.xml里的<profiles>节点可以解决。

profile相当于一套环境预设。可以在里面配置maven.compiler.source和maven.compiler.target，让Maven在编译时默认使用指定JDK版本。示例：

<profiles> <profile> <id>default-jdk</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> <maven.compiler.release>17</maven.compiler.release> </properties> </profile> </profiles>

activeByDefault设为true，表示这个profile默认激活。之后你在IDE里新建Maven项目或命令行直接mvn compile，都会自动用JDK17的编译级别，不用再到IDEA的Project Structure里改locale。

有人会问source和target有什么区别？简单说，source决定源码语法允许用哪个版本的特性，target决定编译出的class文件目标版本。release是更新的写法，同时管了source和target，还避免了用高版本JDK编译低版本target时误用了新API的问题。如果你还在用JDK8，把上面改成8即可。

3.4 一份可以直接抄的settings.xml

为了省去大家东拼西凑，我把上面的配置整合成一份相对完整的settings.xml，直接覆盖到你的conf/settings.xml就能用。注意Java版本按自己的JDK调整：

<?xml version="1.0" encoding="UTF-8"?> <settings xmlns="http://maven.apache.org/SETTINGS/1.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd"> <localRepository>D:/MavenRepo</localRepository> <mirrors> <mirror> <id>aliyunmaven</id> <name>Aliyun Public</name> <url>https://maven.aliyun.com/repository/public</url> <mirrorOf>central</mirrorOf> </mirror> </mirrors> <profiles> <profile> <id>default-jdk</id> <activation> <activeByDefault>true</activeByDefault> </activation> <properties> <maven.compiler.source>17</maven.compiler.source> <maven.compiler.target>17</maven.compiler.target> <maven.compiler.release>17</maven.compiler.release> <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding> </properties> </profile> </profiles> </settings>

修改完settings.xml后，如果IDEA正在运行，需要重启或重新导入一次Maven配置才会生效。命令行不需要重启，直接跑命令即可。

提示：如果你用的是IDEA，它会优先读取IDEA里指定的User settings files路径，而不是Maven安装目录下的conf/settings.xml。所以改完文件之后，最好到IDEA的Maven设置里确认路径，见第4章。

4. 让IDEA真正认账：集成Maven的关键设置

Maven命令行能跑通只是基础，日常开发的主力场景还是在IDEA里。IDEA默认带了Maven，但如果你希望它使用自己刚装的Maven和刚配好的settings.xml，就得动几个设置。这里的坑非常多，包括“maven工具栏不见了”“idea识别不了maven项目”这种热搜词汇，基本都是设置没对位导致的。

4.1 Maven home path与User settings file

打开IDEA，进入Settings→Build, Execution, Deployment→Build Tools→Maven，你会看到几个关键选项：

• Maven home path：选择Maven安装目录。可以选IDEA自带的Bundled，也可以点...选你刚解压的D:\Maven\apache-maven-3.9.9。这里强烈建议选你自己的版本，因为IDEA捆绑的Maven版本相对固定，且日志提示有时会误导新手判断到底用的哪个版本。
• User settings file：右侧有个Override复选框，勾上后可以选择settings.xml文件路径。如果你刚改的是D:\Maven\apache-maven-3.9.9\conf\settings.xml，就把这个路径填这里，IDEA会读取其中的localRepository和mirror配置。不勾Override时，IDEA会用~/.m2/settings.xml，如果这个文件不存在，就用默认配置——前面刚配的镜像就白配了，这其实就是许多人改了settings.xml后IDEA还是下载慢的根源。
• Local repository：这项一般会自动从settings.xml中读取。如果显示的还是C:\Users\xxx\.m2\repository，说明settings.xml没被正确加载，回到上一步检查Override和路径。

改完之后，重点来了：到IDEA右下角或Maven工具窗口点击Reload All Maven Projects图标，让IDEA重新读取配置。如果依赖还是一堆红，再到File→Invalidate Caches / Restart清一次缓存。

4.2 新建项目默认配置的全局模板

上面设置是针对当前项目的。如果你希望以后每个新项目自动使用这套配置，得改Settings里的默认模板。

具体路径：File→New Projects Setup→Settings for New Projects（新版IDEA）或File→Other Settings→Default Settings（老版本IDEA）。进去后在同一个Maven菜单下配置Maven home path和User settings file，这样新建的所有项目都默认加载你的配置。

这一步很多人会漏掉，结果就是每次新建项目都要重新配一遍IDEA的Maven集成。花两分钟把默认模板设好，后续新项目的依赖下载速度、JDK编译级别全部一步到位。

4.3 maven工具栏消失与项目识别问题

有些时候，你在IDEA里打开一个Maven项目，侧边栏却找不到Maven工具窗口，或者IDEA完全不认为这是个Maven项目。这种情况通常有几种原因：

第一，项目根目录下没有pom.xml，或者IDEA没把pom.xml识别为Maven构建文件。这时候在IDEA里右键pom.xml，选择Add as Maven Project，Maven工具窗口就会出现。

第二，IDEA缓存异常。依次尝试File→Invalidate Caches，重启IDEA。如果还是不行，到项目目录下删除.idea文件夹（注意先备份本地配置），重新用IDEA打开项目，让它重新导入。

第三，项目本身太大或者依赖解析卡住，导致IDEA一直处于加载状态。这时候打开Maven工具窗口，看底部进度条是不是卡在Downloading。如果卡住了，确认settings.xml里镜像是否正确，或者用命令行进项目目录执行mvn clean compile -U，先把依赖拉到本地，再回IDEA刷新。

4.4 第一个Maven项目的打包运行

配置和IDEA都搞定了，建议从头跑一个最简单的Maven项目验证全链路。

命令行快速创建骨架：

mvn archetype:generate -DgroupId=com.example -DartifactId=demo -DarchetypeArtifactId=maven-archetype-quickstart -DinteractiveMode=false

生成后进入目录，执行：

mvn clean package

看到BUILD SUCCESS，再在target目录下执行：

java -cp target/demo-1.0-SNAPSHOT.jar com.example.App

如果正常打印出Hello World，那你的Maven环境从下载、配置、编译到打包全链路就通了。接着用IDEA打开这个项目，确认右侧Maven窗口能正常显示lifecycle和dependencies，再往pom.xml里加一个第三方依赖比如com.google.guava:guava:33.0.0-jre，点Reload后能看到依赖成功下拉，这一步走通，后面开发就顺畅了。

5. 依赖下载与编译失败的高频问题排查

配置篇结束，下面进入真正的“实战踩坑”环节。以下问题都是我见过的新手热门提问，也是热搜榜里反复出现的词：依赖爆红、本地有包但引不进来、clean install找不到东西、老环境兼容问题。排查思路比最终命令更重要，我会把链路完整写出来。

5.1 依赖爆红拉不下来怎么办

pom.xml里出现红色波浪线，悬停显示类似“Cannot resolve com.mysql:mysql-connector-j:8.4.0”。第一步不是去改pom，而是确认依赖坐标本身存在。

确认方式：去阿里云仓库网页版入口（maven.aliyun.com里可以搜索依赖，或者直接搜对应jar包名）查这个坐标是否存在、版本号是否正确。经常有人把版本号写错一位，比如8.4.0写成8.4.0.1，那就永远拉不到。

坐标正确但依然爆红，接下来按这个顺序排查：

1. 检查mvn -v能正常执行，确认环境变量没问题。
2. 检查IDEA里User settings file是否指向了你配了镜像的settings.xml。这一步能过滤掉一半问题。
3. 去本地仓库目录，看对应groupId路径下有没有下载了一半的.lastUpdated文件。有的话说明上次下载没完成，Maven为了性能会缓存失败状态。处理办法是删除本地仓库中该依赖对应的整个目录，然后重新Reload。
4. 命令行强制刷新：在项目根目录执行mvn clean install -U，-U参数强制检查远程仓库的最新版本，能绕过很多本地缓存导致的“假失败”。

如果你用的是命令行下载成功、IDEA里还是爆红，多半是IDEA没读最新本地仓库。在IDEA里执行一次Reimport All Maven Projects，如果还不行就Invalidate Caches重启。别小看最后一步，IDEA的索引缓存有时就是赖着不更新。

5.2 本地明明有jar包却引不进去

这个场景很经典：你从同事那拷了一个jar包，本地仓库对应目录里确实有文件，IDEA却依然报找不到。问题往往出在“Maven本地仓库里的目录结构和坐标不匹配”。

Maven查找依赖不是按文件名匹配的，而是按坐标（groupId/artifactId/version）去本地仓库的对应路径下找，并且还要校验对应的_remote.repositories、.lastUpdated和pom文件。如果你只是手工扔了一个jar包进某个目录，但缺少对应版本的pom文件，Maven依然认为这个依赖不存在。

正确的“把本地jar包装进本地仓库”方法是使用install-file命令：

mvn install:install-file -Dfile=your.jar -DgroupId=com.example -DartifactId=your-lib -Dversion=1.0.0 -Dpackaging=jar

执行完成后，Maven会自动生成规范的目录结构和pom文件，这时再在项目pom.xml里声明坐标，IDEA刷新后就能正常识别。如果这个方法暂时不想用，也可以直接让项目以系统依赖方式引用jar包，但那只适合临时验证，别用进生产代码。

另一个“本地有但引不进”的原因是依赖冲突。比如项目里两个不同的传递依赖把同一个jar的不同版本都拉进来了，Maven选择了其中某个，而你的代码又需要另一个的类，这样IDEA会爆红。排查命令：

mvn dependency:tree

看输出里这个依赖出现的路径，再去dependencyManagement里锁定版本。

5.3 clean install到底该在什么位置执行

新手最容易问：“我在IDEA哪里点clean install？”或者“为什么我执行mvn clean install报错”。

先明确一个概念：Maven命令的执行位置必须是包含pom.xml的模块目录。你在项目根目录执行没问题，在某个子模块目录执行就是只构建那个子模块。多模块项目里，父pom和子pom都有各自的构建范围，执行位置不对，构建出来的结果就不对。

常见的错误是把命令跑在了src目录或者target目录里。还有一种是项目里存在模块依赖，你单独在某个子模块执行mvn clean install，结果它依赖的另一个模块还没install到本地仓库，就会报“Could not resolve dependencies”。解决办法：多模块项目最好直接在父工程根目录执行mvn clean install，通过-pl 模块名 -am参数精准控制构建范围，而不是逐个子模块单独跑。

IDEA里执行则简单很多：右侧Maven工具窗口展开对应模块的Lifecycle，双击clean和install即可。如果Lifecycle里没东西，要么项目没被识别为Maven项目，要么pom文件有语法错误，先看IDEA底部Messages窗口的报错。

5.4 老系统与低版本JDK的兼容问题

最后聊两个看起来吓人、实际原因很清晰的老环境报错。

第一个是编译报错找不到com.sun.image.codec.jpeg.JPEGCodec。这个类在JDK8及更早版本里存在，但从JDK9开始被移出JDK或者默认不开放访问。如果你的代码里用了它，大概率是为了处理JPEG图片编码。解决办法有两个方向：一是把编译和运行环境降到JDK8；二是改代码，用标准的javax.imageio.ImageIO替换。后者是正路，这个私有API早就被官方标记为不建议使用了，越早换越好。

第二个是“maven编译项目报找不到类”但代码里明明有。常见原因有两种：IDE的缓存与Maven的target目录不同步，先mvn clean再重新编译；或者模块间依赖没有正确声明，A模块引用了B模块的类，但pom里没加B的依赖，编译时自然找不到。这类问题先mvn dependency:tree看依赖关系，再检查pom声明，比瞎改代码高效得多。

第三个是IDEA启动项目失败，且日志里有大量java.lang.NoClassDefFoundError或ClassNotFoundException。这种通常是运行时依赖缺失，检查IDEA的Run Configuration里Classpath是否选了use classpath of module，以及模块的Scope有没有把provided或runtime依赖错配。最简单的验证方式：命令行里能跑通mvn spring-boot:run，IDEA里却启动失败，九成是IDEA运行配置和依赖范围设置的问题，而不是代码问题。

写在最后的建议

整套安装配置走到这里已经接近尾声。我个人体验最深的一点是：Maven的问题很少是Maven本身坏掉，绝大多数是配置文件路径不对、镜像没配、或者本地仓库里残留了失败记录。所以遇到任何Maven异常，先别重装软件，按“环境变量 → settings.xml → 本地仓库状态 → 项目pom → IDEA设置”这个顺序去排查，基本都能找到根因。

最后再分享一个小习惯：每次改完settings.xml或IDEA配置，我都会在命令行执行一次mvn help:effective-settings，这个命令会把真正生效的配置全部打印出来，包括最终加载了哪些镜像、本地仓库在哪。一眼就能看出自己的修改有没有被Maven读到，比在IDEA里反复刷新盲猜高效得多。装Maven这件事，做到这一步，就算彻底盘明白了。