1. 到底为什么要折腾镜像配置先聊一个所有Java开发者都绕不开的痛点用Maven拉依赖卡到怀疑人生。一开始用Maven的时候本地~/.m2/repository空荡荡任何一个新项目第一次执行mvn clean install都像开了一场盲盒抽奖。运气好三五分钟搞定运气不好某个依赖卡在中央仓库上下到一半直接超时连带整条构建链路全废。真正用过默认中央仓库repo.maven.apache.org的人都知道那种下载进度条半天不动的感觉足够让人把Maven换掉。国内镜像配置就是干这个的把Maven默认的中央仓库地址替换成国内访问速度更快的镜像站点。项目里依赖照常声明构建命令一行不用改依赖下载速度却能提升几十上百倍。配置好之后新项目从零开始执行构建几分钟内就能把几百个依赖全部拉完中途不需要任何人工干预。这篇内容适合所有用Maven做Java构建的人不管你是刚入门的新手还是已经写了三年Java的老伙计。特别是以下几种情况这篇内容对你价值最大没有公司私服一直用公网中央仓库下载速度常年看运气公司有私服但私服时好时坏想加一个公网镜像兜底换了新电脑或新环境想一次性把Maven配置到位遇到下载失败、Checksum validation failed、UnknownHostException这类花式报错这里先给你一个确定的结论在国内开发环境下只改一个settings.xml文件、加几行mirror配置就能解决95%以上的Maven下载问题。剩下5%是私服认证、仓库组策略、网络代理那些进阶场景会在后面单独拆开讲明白。2. Maven仓库机制与镜像配置的核心逻辑2.1 仓库、镜像、仓库组之间的关系聊配置之前先把Maven仓库这套机制搞清楚。很多人配置镜像只背结论不改脑子结果换个环境又栽跟头问题就出在没理解原理。Maven项目里声明的依赖最终都要从一个仓库里拉取。这个仓库可以是公网的中央仓库可以是公司内部架设的私服也可以是你本地电脑上已下载的依赖缓存。Maven的依赖解析优先级是本地仓库优先本地仓库没有才去远程仓库下载。镜像Mirror是什么它解决的问题是远程仓库地址的“搬移”。你不想直接访问repo.maven.apache.org于是配置一个镜像让Maven访问一个国内站点但实际上这个国内站点背后同步的仍然是中央仓库的内容。对Maven来说镜像就像一个透明中转站仓库的“身份”不变只是访问地址变了。仓库组Repository Group则是Nexus这类私服工具里的常见概念。一个仓库组可以把多个仓库聚合到一个URL下面。比如阿里云Maven镜像里的public仓库组就聚合了Maven中央仓库、JCenter仓库、Google等几个常用仓库的内容。你配置镜像指向public等同于一次性对接了几个仓库的合集。2.2 镜像配置的匹配规则镜像配置的核心是mirrorOf标签它决定“哪些仓库要使用这个镜像”。这个标签有几种写法每一种使用场景都不同mirrorOfcentral/mirrorOf只镜像中央仓库。适合已经有了公司私服只想给本地构建加“从中央仓库直连下载”加速的场景。这种写法对其它仓库不生效最精准也最安全。mirrorOf*/mirrorOf匹配所有仓库。不管项目里配置了哪个远程仓库全部走这个镜像地址。适合新人第一次配置镜像省心。但这种写法有个坑如果你的pom.xml里配置了公司内部私服地址它也会被“劫持”到公网镜像上导致私服依赖拉不到。mirrorOf*,!my-private-repo/mirrorOf匹配所有仓库但排除my-private-repo。这是“全部走镜像但给私服留一条生路”的写法适合既需要公网镜像加速、又需要访问公司私服的场景。mirrorOfexternal:*/mirrorOf只匹配非本地的远程仓库。在某些内网隔离场景下这种写法能规避一些奇怪的路由问题。我的建议很简单新人直接照抄mirrorOfcentral/mirrorOf这个写法的兜底能力最强永远不用担心把私服地址全局劫持了。等踩过几次坑再按需调整即可。2.3 选择镜像源时要看什么指标不同镜像源的同步频率、稳定性、仓库组覆盖范围差异不小。选镜像源不是看谁广告打得响而是看三个核心指标。第一同步频率。镜像站点不是你自己搭的是人家同步了中央仓库的内容后才对外开放。同步频率决定了你能否第一时间拉取“昨天刚发布”的依赖版本。有些镜像同步间隔是6小时有些是1小时差距在依赖版本逆天更新的时候会非常明显。第二仓库组的覆盖范围。以阿里云镜像为例public仓库组下挂了central中央仓库、jcenterJCenter仓库、googleGoogle仓库等几个内容源。如果你的项目里用到了某些只在JCenter上发布的库直接指向public仓库组就能拉下来而指向单独的central镜像则大概率404。第三长期稳定性。镜像站点的维护情况你真的判断不了只能通过“出现事故后多久恢复”这个指标来感受。我在多个镜像源之间切换过其中一些镜像在特定时间段的下载速度会明显掉下去而另一些则一直很稳。整体感觉是大厂托底的镜像遇到问题的修复速度更快容错能力也更强。2.4 为什么配置镜像要多备一个源这是我自己实践下来最想提醒你的一件事只配一个镜像源风险一点都不低。某个镜像站点偶尔会出现网络抖动、同步延迟、服务升级这时候你整个构建流程都会卡住。而Maven镜像配置本身支持多镜像备援按顺序尝试一个失败会自动切下一个。多备一个源相当于给你的构建流程上了一道保险。配置多个镜像时要把最常用的源写在前面兜底源写在后面。比如公司环境里的首选源是阿里云的仓库组那把它写在一个优先级最高的位置。备源写腾讯云的仓库组或华为云的仓库组它们的地址不同、网络线路不同同时挂的概率极低。3. 主流国内Maven镜像源盘点与选型3.1 国内常用镜像源一览网上流传的镜像源名单很杂我在不同阶段试过不少最后稳定在几个长期都在维护的源上面。这里我从自身使用频率出发按“首选、备选、特殊情况”三个梯队做一个盘点数据是截至本文发布时点的实测情况。镜像源仓库组地址特点与使用建议阿里云https://maven.aliyun.com/repository/public综合体验最好仓库组覆盖广文档全推荐首选腾讯云https://mirrors.cloud.tencent.com/nexus/repository/maven-public/腾讯内部同步源速度稳定适合作为备源华为云https://repo.huaweicloud.com/repository/maven/华为云维护同步质量不错适合网络环境特殊时切换开源中国https://maven.oschina.net/repository/maven-public可用性相对一般现在新的使用场景下不太推荐优先使用网易https://mirrors.163.com/maven/repository/maven-central/覆盖范围相对窄有时候会遇到冷门依赖缺失的情况以上地址都是我实际配置过、验证可用的。如果你换了新的工作站或容器环境复制粘贴加上去就能跑。3.2 为什么阿里云镜像是多数人的首选阿里云Maven镜像的地址是https://maven.aliyun.com/repository/public对应仓库组public。这个仓库组聚合了central、jcenter、google等几个常用仓库的内容绝大多数开源Java项目依赖都能在它上面找到。阿里云镜像我最满意的点是它的容错做得非常好。构建过程中如果某个依赖在这个站点上暂时缺失Maven本身会报错失败但极少出现“下载一半连接断开”这类让人抓狂的情况。下载速度方面在普通家庭宽带环境下稳定跑到10MB/s以上没什么问题。另外阿里云还提供了独立的central仓库地址https://maven.aliyun.com/repository/central如果你只需要中央仓库内容、不想让JCenter和Google仓库混进来部分公司内部策略会嫌仓库污染可以只指向这个独立地址。3.3 多镜像源按场景配置的思路不同环境下镜像源的优先级是可以灵活调整的。我这里按自己实际遇到过的几类场景对应说明。场景一个人开发无公司私服。首选直接配阿里云public仓库组备选加一个腾讯云仓库组。这个组合对绝大多数个人项目足够。场景二公司有Nexus私服但私服需要同步中央仓库。这种情况不要用公网镜像把所有仓库都“劫持”走否则私服本身的远程仓库同步路径也会变得很混乱。你应该在私服的仓库配置里把远程仓库地址指向国内镜像私有仓库仍然保留原始地址。场景三构建环境在北京/上海等网络出口较复杂的机房。某些机房的网络出口对某些云厂商的访问质量波动很大。如果阿里云镜像卡直接切到腾讯云或华为云镜像实测能救急的概率在八成以上。场景四内网隔离环境只有一台跳板机能访问外网。这种环境不要直接给本地Maven配公网镜像正确做法是找一台内网机器搭Nexus在Nexus的远程仓库里配置国内镜像地址开发机全部指向内网Nexus。3.4 镜像源同步延迟踩坑记录镜像同步延迟是隐藏很深的一个坑。什么意思就是某个版本的依赖已经在Maven中央仓库发布了但镜像站点还没来得及同步过来你构建的时候就会报“找不到该版本”的错误。我自己遇到过很典型的一次同事当天急着用最新版的一个测试库本地Maven配置的是某小众镜像源结果这个镜像源的同步策略是每12小时才同步一次一直拉不到那个版本。后来切换到阿里云镜像同一份pom.xml依赖秒下。原因很简单阿里云的同步频率比那个小众源高太多。所以我的结论是尽量不要选同步频率低的镜像源作为唯一源。你把同步频率写在纸上当你遇到“明明中央仓库有镜像源却拉不到”的诡异问题时第一反应就应该去检查镜像源同步状态。4. settings.xml配置实操与关键技术点4.1 找到正确的settings.xml文件Maven的配置信息集中在settings.xml文件里。看清楚是settings.xml不是pom.xml。pom.xml管的是某个项目怎么构建settings.xml管的是你本机Maven的全局行为。settings.xml有两个层级层级文件位置生效范围全局配置Maven安装目录下的conf/settings.xml影响这台机器上所有用户的所有项目需要管理员权限修改用户配置~/.m2/settings.xmlWindows下是%USERPROFILE%\.m2\仅影响当前用户优先级高于全局配置新手常常搞混的一点是“我改了全局配置为什么项目里不生效”答案大概率是用户配置里有旧的镜像配置用户配置的优先级高于全局配置把全局配置覆盖掉了。我建议的稳妥做法是把用户的~/.m2/settings.xml作为主配置文件统一管理。不管Maven装在哪只要用户的settings.xml里配置正确构建就一定能吃到这套镜像配置。4.2 独立镜像配置写法最简单方案如果不想动公司私服的配置只是想加速中央仓库的下载一个独立的mirror节点就够了。下面是我推荐的最小化配置settings mirrors mirror idaliyun-public/id namealiyun public/name urlhttps://maven.aliyun.com/repository/public/url mirrorOfcentral/mirrorOf /mirror mirror idtencent-maven/id nametencent maven/name urlhttps://mirrors.cloud.tencent.com/nexus/repository/maven-public//url mirrorOfcentral/mirrorOf /mirror /mirrors /settings这段配置的含义是所有对中央仓库的请求优先走阿里云镜像如果阿里云镜像不可用Maven才会尝试第二个腾讯云镜像。要注意的是两个id不能重复。id是Maven区分镜像源的唯一标识如果两个镜像源配了相同的id后配置的会把先配置的完全覆盖掉第一个镜像源等于白配了。4.3 包含私服与镜像的统一配置个人开发环境可能同时存在“本地Maven需要访问公司私服”和“中央仓库需要走国内镜像”两个需求。这时候mirrorOf的匹配规则就非常讲究了。先看一个我实际在用的完整配置settings !-- 配置本地仓库位置 -- localRepositoryD:\maven-repo/localRepository !-- 配置镜像 -- mirrors !-- 中央仓库走阿里云镜像 -- mirror idaliyun-central/id namealiyun central mirror/name urlhttps://maven.aliyun.com/repository/central/url mirrorOfcentral/mirrorOf /mirror !-- 其它所有仓库除了公司私服走阿里云public -- mirror idaliyun-public/id namealiyun public mirror/name urlhttps://maven.aliyun.com/repository/public/url mirrorOf*,!company-nexus/mirrorOf /mirror /mirrors !-- 配置私服账号密码发布构件到私服时需要 -- servers server idcompany-nexus/id usernamedeploy-user/username passwordyour-password/password /server /servers /settings关键点拆解如下。第一mirrorOfcentral/mirrorOf先精准拦截中央仓库请求指向阿里云专门同步中央仓库的地址。这保证了对大多数开源依赖的加速。第二mirrorOf*,!company-nexus/mirrorOf再兜底匹配所有其它远程仓库但用!把company-nexus这个id排除掉确保公司私服的请求不会走公网镜像。第三servers节点里的id必须和项目pom.xml里配置的repository/snapshotRepository的id一致。Maven凭这个id匹配账号密码id对不上就会被判定为未认证发布构件时报401错误。一个容易忽略的细节localRepository的路径建议和Maven默认路径分开。很多人习惯把本地仓库放在默认的~/.m2/repository一旦电脑重启或系统重装整个仓库缓存全部丢失又得全部重新下载。我习惯把本地仓库指到一个独立数据盘或专门的目录重装系统后不用全部重拉。4.4 Maven 3.8对HTTP协议的阻断问题这是新人配置镜像时最常踩的一个坑值得单独拿出来讲。Maven 3.8.1起引入了一个默认阻止HTTP仓库的机制如果你配置的镜像地址是http://开头的非HTTPS地址Maven构建时会直接报一个“Blocked Mirror”错误并在日志里提示有一个名为maven-default-http-blocker的外部HTTP仓库拦截器。具体报错长这样[ERROR] Failed to execute goal on project xxx: Could not resolve dependencies for project xxx: The following artifacts could not be resolved: ... Blocked mirror for repositories: [central (http://...) ]这个机制的本意是安全防护防止构建过程被不安全的HTTP仓库篡改依赖但在国内配置镜像时方向反了不少人抄了一个老旧的HTTP镜像地址结果被Maven内部机制卡住。解决方法有三种把镜像地址换成HTTPS。目前国内主流镜像都支持HTTPS这是最省事的办法。如果确实只能用HTTP比如内网自建的HTTP私服需要在profiles里显式配置一个不拦截该仓库的仓库定义且在mirrors中把该仓库排除掉。直接改Maven全局配置里的maven-default-http-blocker拦截规则。我推荐第一种方法。现在几乎所有正规镜像源都上了HTTPS遇到“Blocked Mirror”报错时优先检查你的镜像URL是不是http://开头改成https://一般立即解决。4.5 超时与重试参数调优Maven下载依赖的过程中如果镜像源在特定时间段不稳定会出现“连接超时”“读取超时”这类错误。默认的超时时间对网络质量较差的国内环境并不友好手动调高能明显降低“下载到一半失败”的概率。在settings.xml里加一个profiles节点配置如下profiles profile idnetwork-timeout-tuning/id properties maven.artifact.threads8/maven.artifact.threads maven.wagon.rto60000/maven.wagon.rto maven.wagon.http.connectionTimeout30000/maven.wagon.http.connectionTimeout maven.wagon.http.readTimeout60000/maven.wagon.http.readTimeout maven.wagon.http.retryHandler.count5/maven.wagon.http.retryHandler.count /properties /profile /profiles这些参数里最实用的是connectionTimeout连接超时时间和readTimeout读取超时时间。默认值一般是几十秒遇到网络抖动时很容易触发失败调到30秒/60秒之后容错能力强很多。maven.wagon.http.retryHandler.count是重试次数默认是3我一般调到5。重试次数太高会拖慢整体构建时间太低遇到网络抖动又扛不住5是一个比较稳的阈值。maven.artifact.threads是并行下载线程数默认只有5对带宽非常充裕的场景来说不够。我自己的实践经验是调到8如果你所在网络带宽很大可以试到10以上但注意不要调到16以上避免因并发请求过多被封禁或拖垮镜像源。5. 实操演示从零到一把配置到位5.1 完整实操流程与验证纸上谈兵没意思跟着我完整做一遍。假设你是在一台全新安装的Linux主机上操作目标是把Maven配置成“全部依赖走国内镜像顺手把私服认证配好”。第一步确认Maven版本和配置文件位置。mvn -v输出里能看到Maven的安装路径。接着找到该路径下的conf/settings.xml这是全局配置再检查~/.m2/settings.xml是否存在不存在就手动创建。mkdir -p ~/.m2 touch ~/.m2/settings.xml第二步写入基础配置。我这里以阿里云public为主源腾讯云为备源。把下面内容原样贴到~/.m2/settings.xml里?xml version1.0 encodingUTF-8? settings xmlnshttp://maven.apache.org/SETTINGS/1.0.0 xmlns:xsihttp://www.w3.org/2001/XMLSchema-instance xsi:schemaLocationhttp://maven.apache.org/SETTINGS/1.0.0 http://maven.apache.org/xsd/settings-1.0.0.xsd localRepository/data/maven-repo/localRepository mirrors mirror idaliyun-public/id namealiyun public/name urlhttps://maven.aliyun.com/repository/public/url mirrorOfcentral/mirrorOf /mirror mirror idtencent-maven/id nametencent maven/name urlhttps://mirrors.cloud.tencent.com/nexus/repository/maven-public//url mirrorOfcentral/mirrorOf /mirror /mirrors /settings第三步创建一个测试项目并执行打包。用一个最简单的Java项目验证即可不必新建完整业务工程。mkdir -p /tmp/maven-demo cd /tmp/maven-demo在pom.xml里简单声明一个依赖比如Gsonproject xmlnshttp://maven.apache.org/POM/4.0.0 modelVersion4.0.0/modelVersion groupIdcom.demo/groupId artifactIdmaven-demo/artifactId version1.0.0/version packagingjar/packaging dependencies dependency groupIdcom.google.code.gson/groupId artifactIdgson/artifactId version2.10.1/version /dependency /dependencies /project第四步执行构建并观察下载速度。mvn clean compile正常情况下你会在日志里看到依赖下载时URL指向maven.aliyun.com下载速度比什么都不配时快一个数量级。用时间对比一下默认中央仓库下这个依赖可能要几十秒甚至超时配置镜像后一般3秒内完成。第五步检查本地仓库缓存是否被正确写入。find /data/maven-repo -name gson-2.10.1.jar能看到jar包文件说明下载成功。缓存在了独立目录之后重装系统也不会丢。5.2 用mvn dependency:resolve验证镜像是否生效有人好奇“我配置了镜像怎么确认它真的生效了”最直接的办法是看构建日志里的下载URL但日志刷新太快容易漏掉。更可控的方式是用mvn dependency:resolve命令。mvn dependency:resolve -X加-X参数会输出调试级别的日志里面会明确记录Maven访问了哪个仓库地址。搜一下日志如果大量出现Downloading from aliyun-public: https://maven.aliyun.com/repository/public/...说明镜像配置已被正确命中。如果出现Downloading from central: https://repo.maven.apache.org/...说明你的镜像规则没覆盖到该仓库需要回头检查mirrorOf的写法。5.3 项目级仓库定义与镜像的交叉影响还有一个经常让人困惑的点项目pom.xml里显式声明了repository会不会绕过settings.xml的镜像配置答案是不会。Maven的镜像规则是全局的不管仓库是在中央仓库默认列表里还是在项目pom.xml里自定义的只要mirrorOf匹配到请求都会先经过镜像。但要注意一个反向场景如果你在项目pom.xml里给某个依赖配了独立的repository且mirrorOf匹配规则包含该仓库的id那么这个请求也会走镜像即使你本意是想直连某个特殊仓库源。所以前面推荐的mirrorOf用*,!company-nexus这样的排除写法就是为了避免这个“全部拦截”的问题。5.4 私服Nexus与镜像配合的经典架构公司在内部搭了Nexus私服开发环境又需要加速中央仓库怎么配比较合理这里分享一个经过验证的经典架构。思路是这样的私服Nexus本身承担“仓库管理和权限控制”的职责而私服远程仓库的下载地址指向国内镜像从而让私服从国内镜像同步依赖开发机统一指向私服。直接结果就是开发机不发任何直接访问公网的请求对安全性要求高的内网更友好同时下载速度完全由公网镜像的同步质量决定。具体步骤在Nexus管理后台创建一个新的代理仓库远程仓库地址填阿里云https://maven.aliyun.com/repository/public仓库名如aliyun-proxy。在Nexus里创建一个仓库组把这个代理仓库和已有的内部托管仓库存放公司自己发布的构件都包含进去。开发机的settings.xml里mirrorOf只匹配central并将URL指向该Nexus仓库组的地址。这套架构里的好处是开发机配置特别简单一个仓库组地址通吃公网依赖和内部依赖不需要维护多套仓库源。坏处也很明显如果私服挂了开发机连内部依赖都拉不了相当于单点故障。所以要给Nexus做备份或容灾这个就看公司运维能力了。6. 常见问题排查与避坑实录6.1 配置了镜像但下载还是慢这是出现频率最高的问题。配置了阿里云镜像但下载速度依然普普通通甚至比默认中央仓库还慢最常见的原因有三个。原因一mirrorOf没匹配对。比如镜像配了mirrorOfcentral/mirrorOf但项目里实际访问的仓库是某个自定义仓库请求根本没走镜像。排查方法是执行构建时加-X看日志里的Downloading from后面到底跟着哪个仓库地址。原因二本地仓库里其实已经有这个依赖了Maven在做“检查版本”而不是“下载依赖”。这时候速度慢的原因不是下载而是Maven在解析依赖树。这种“假慢”很迷惑人最直接的判断方式是把-U参数加上强制刷新快照观察构建耗时。原因三settings.xml里同时配置了多个镜像但后配的镜像覆盖了先配的。这个常见于前人改过的配置文件后人直接往里面追加结果镜像的id冲突后一个覆盖前一个。排查时看mvn help:effective-settings命令它会输出当前所有配置合并后的有效结果。6.2 下载失败、校验和报错、UnknownHostException这几个报错虽然属于不同异常类型但根因往往是同一个方向镜像源不稳定或者仓库地址无法解析。Checksum validation failedjar包下载不完整Maven在验证校验和时发现文件损坏。解决方案是删除本地仓库里对应的.lastUpdated文件后重新构建或者直接清理整个依赖目录让Maven重新下载。UnknownHostException你配置的镜像域名根本解析不了。比如某些镜像源已经停止服务或更换域名。解决方式是换一个镜像地址如果在内网环境可能是DNS配置问题。Connect timed out域名解析成功但TCP连接超时大概率是该镜像源在特定网络区域被限制或拥堵。首选切换镜像源备选调大连接超时时间。我自己遇到最挫败的一次是某个小众镜像源在晚间高峰时段整体不可用团队里所有依赖下载全部超时当时立刻切成阿里云镜像恢复了构建。那次之后我建立了“绝不在生产环境只配单一镜像源”的底线。6.3 私服仓库中的SNAPSHOT依赖问题SNAPSHOT版本和release版本的处理逻辑完全是两套。很多公司会在私服里托管SNAPSHOT版本的内部依赖同时让它们从镜像同步中央仓库的SNAPSHOT内容。如果你用mirrorOf*/mirrorOf把私服仓库也劫持到公网镜像那SNAPSHOT依赖会全部走公网镜像私服上独有的SNAPSHOT构件必然404。正确的处理方式是mirrorOf用排除写法确保私服仓库的id不被匹配到前面举的*,!company-nexus就是标准写法。同时在pom.xml或settings.xml的repositories里明确声明私服仓库并配置snapshotsenabledtrue/enabled/snapshots来允许拉取快照版本。6.4 常见报错速查表这里把实操中容易遇到的各种情况汇总成一张速查表方便你“对号入座”。报错信息可能原因解决办法Blocked mirror for repositories镜像URL是HTTP被Maven 3.8默认拦截换成HTTPS地址或调整maven-default-http-blocker规则UnknownHostException镜像域名不可解析检查镜像地址是否过期检查内网DNS配置Connect timed out与镜像源网络不通切换备用镜像调大连接超时检查防火墙Read timed out下载过程中读取数据超时调大maven.wagon.http.readTimeout重试Checksum validation failed下载文件损坏或不完整删除本地仓库对应目录重新下载Could not find artifact ... in aliyun-public镜像仓库中没有该构件换public仓库组检查同步频率用其它镜像源Return code is 401私服鉴权失败检查servers里的账号密码是否匹配私服idReturn code is 404私服或镜像上没有该构件检查仓库组是否包含该仓库检查项目仓库配置~/.m2/repository中没有对应依赖本地仓库路径被修改检查localRepository配置使用绝对路径6.5 缓存清理的几种姿势镜像配置改了好几次但问题一直没解决可以考虑清理本地缓存让Maven强制重新下载。这里给出几种不同力度的清理方式。# 删除某个特定依赖的缓存及.lastUpdated文件 rm -rf ~/.m2/repository/com/google/code/gson/gson # 删除目录下所有.lastUpdated缓存记录推荐解决大部分因失败残留导致的下载异常 find ~/.m2/repository -name *.lastUpdated -delete # 全量清空本地仓库慎用代价是要重新下载所有依赖 rm -rf ~/.m2/repository/*.lastUpdated文件是Maven下载失败后留下的标记。如果你的依赖下载中途失败下次构建时Maven可能因为存在.lastUpdated而直接判定“该版本不存在”不去重新尝试下载。定期清理.lastUpdated文件很多莫名其妙的“找不到依赖”问题可以直接解决。7. 从提升速度到维护仓库健康镜像配置解决的是“下载慢”的问题但一个健康的Maven仓库还需要做到版本收敛与依赖可控。很多项目跑了几个月后依赖数量越来越多mvn dependency:tree的输出一屏都放不下版本冲突满天飞这才是比镜像更让人头疼的事。我的建议是定期用mvn dependency:tree分析依赖树重点关注同一个依赖是否出现了多个不同版本版本冲突是否有依赖被错误地传递到了生产打包物里某些废弃API对应的老版本是否还在被使用镜像源可以让下载速度变快但它不会帮你规避依赖本身的问题。真正健康的Maven工程需要依赖版本有规划、仓库源有冗余、构建速度可预期。另外如果你所在团队的Maven项目很多建议统一维护一份标准的settings.xml放在内部配置管理平台里新人入职直接拉取使用。这样可以避免每个人各自为战、配置文件五花八门、镜像源各不相同导致的“我这边能编译、你那边就报错”的尴尬局面。团队统一镜像源、统一JDK版本、统一构建工具版本很多协作问题能直接消失。关于Maven国内镜像的配置核心思路就是四件事选一个可靠的镜像源、配好mirrorOf匹配规则、处理好HTTP阻断问题、通过多源冗余保障构建稳定。把这四件事做到位不比别的至少你的构建体验能领先大多数人一个身位。
