Maven依赖查找是单向线性链：本地仓库优先，命中即停；远程仓库无固定层级，顺序由settings.xml中<mirrors>和<profiles>配置决定，按出现顺序逐个尝试，首个HTTP 200响应即终止查找。
本地仓库永远是第一道门
只要 ~/.m2/repository（或 settings.xml 中自定义路径）里有对应坐标（groupId:artifactId:version）的完整构件（含 .jar 和 .pom），Maven 就直接用，不发任何网络请求。它不关心这个版本是不是旧的——比如本地存着 junit:junit:4.12，就算私服和中央仓都有 4.13.2，也不会自动升级。
想强制刷新元数据（比如检查远程是否有新版本），得加 -u 参数：mvn clean compile -u；或者手动删掉本地对应目录。
远程仓库没有固定层级，只有配置顺序
Maven 不内置“私服 > 中央仓”这种硬编码优先级。真实顺序由 settings.xml 中的 <mirrors> 和激活的 <profiles> 共同决定，pom.xml 里的 <repositories> 只能新增或覆盖，不能改变尝试顺序。
- 如果
<mirrorOf>*</mirrorOf>，所有远程请求（不管原目标是 central 还是其他 repo）都会被重定向到该镜像——此时它就成了唯一的远程入口； - 如果
<mirrorOf>central</mirrorOf>，只代理中央仓库请求，其他自定义仓库仍按原路径访问； - 没配镜像时，Maven 默认只连中央仓库（
https://repo.maven.apache.org/maven2/）； - 配了多个
<repository>，Maven 按它们在settings.xml或pom.xml中出现的顺序逐个试，**第一个返回 HTTP 200 的仓库就是最终来源**，后面不再继续查。
私服本质是“带缓存的远程仓库”，不是独立层级
企业搭 Nexus 或 Artifactory，目的不是增加一个“更高优先级”的仓库，而是把它设为所有远程请求的统一出口（即配置成 <mirrorOf>*</mirrorOf>）。这时流程变成：
立即学习“Java免费学习笔记（深入）”；
- 本地没找到 → 请求私服；
- 私服本地有 → 直接返回并下载到开发者本地仓库；
- 私服本地没有 → 私服自己去中央仓（或其他上游仓库）拉取 → 缓存后返回给开发者。
这个过程对 Maven 客户端是透明的：它只和私服打交道，不知道也不关心私服背后连了几个上游源。
依赖不会“降级”或“跨仓比对”
不存在“先查私服没找到，再查中央仓，发现中央仓有更老版本就用它”这种行为。Maven 查找是严格的“命中即停”：
- 本地有 v1.0 → 用 v1.0；
- 本地没有，但镜像指向阿里云 → 只问阿里云，哪怕它没同步最新版；
- 阿里云返回 404 → 构建失败，不会自动 fallback 到中央仓或其他仓库。
所谓“逐级”，其实是运维人为设计的代理链（本地 → 私服 → 中央仓），不是 Maven 内置机制。
