mirrorof 是 maven 镜像生效的必要开关，必须明确配置匹配规则；留空、注释或误用 会导致镜像失效或私有仓库被错误代理，应按优先级顺序配置 central、external: 等值并排除内部仓库。
mirrorOf 不写就等于没配
很多开发者把 mirror 块复制进 settings.xml 后发现阿里云或腾讯云镜像根本没生效，最常见原因就是 <mirrorof></mirrorof> 标签被漏掉、注释掉，或者留空。Maven 的镜像机制是“按规则拦截”，不声明匹配范围，它压根不会去碰这个镜像。
-
<mirrorof></mirrorof>是开关，不是可选项；留空或注释 = 镜像闲置 - 常见错误配置：
<mirrorof></mirrorof>或<!-- <mirrorOf>central</mirrorOf> --> - 一旦缺失，Maven 会退回到默认行为：直连
https://repo.maven.apache.org/maven2，国内用户大概率卡在下载阶段
mirrorOf 匹配顺序决定谁生效
Maven 不会“智能选最优”，它只按 <mirrors></mirrors> 列表从上到下逐个比对，第一个 <mirrorof></mirrorof> 匹配成功的镜像就立即使用，后面的直接跳过。这意味着顺序本身就是策略。
- 精确匹配优先：比如
<mirrorof>central</mirrorof>和<mirrorof>*</mirrorof>同时存在，请求central仓库时，前者命中即止，不会继续往下看 - 多个镜像都匹配
central？Maven 按<id></id>字母序选第一个（如aliyunvscentral-fallback，aliyun先胜） - 想设兜底镜像？把
<mirrorof>*</mirrorof>放在列表最后，前面放具体仓库的专用镜像
mirrorOf 常见值怎么选：别乱用 *
* 看起来省事，但实际极易引发问题——它会把所有远程仓库（包括你项目里手动配的私有 repository）一并重定向，导致内部构件拉不到、SNAPSHOT 版本失效、甚至构建失败。
-
central：安全选择，只加速 Maven 中央仓库，不影响项目级自定义仓库 -
central,jcenter：需显式列出多个 ID，逗号分隔，注意 jcenter 已停服，慎用 -
external:*：拦截所有非file://协议的仓库，排除本地仓库，相对稳妥 -
*,!my-internal-repo：匹配所有，但排除 ID 为my-internal-repo的仓库；注意!必须紧跟逗号，不能有空格
镜像和仓库配置混用时的真实流向
很多人以为在 pom.xml 里写了 <repository></repository>，Maven 就一定会去那里拉包——其实不一定。如果 settings.xml 里有个 <mirrorof>*</mirrorof>，那个项目级仓库也会被强行代理过去，而镜像源很可能根本没有它的构件。
- 流程是：POM 中声明仓库 → Maven 解析其
<id></id>→ 检查settings.xml中是否有<mirrorof></mirrorof>匹配该<id></id>→ 匹配则走镜像 URL，否则走原<url></url> - 企业私有仓库必须确保不被公共镜像覆盖，推荐用
<mirrorof>external:*</mirrorof>+ 显式排除（如*,!nexus-prod） - 调试技巧：加
-X参数运行mvn compile，搜索日志里的Using mirror行，确认实际走的是哪个地址
镜像配置真正难的不是写对标签，而是理解“谁在什么时候被谁替换”。mirrorOf 是一个拦截规则，不是加载开关；它和 repository 是两套独立又交叉的寻址逻辑，稍不注意就会让依赖从私有仓库悄悄流到公网镜像，或者反过来，让加速失效。
