IDEA里添加依赖后，代码就能引用新类。可换台电脑，为什么可能突然报红？

答案藏在pom.xml、本地缓存和远程仓库之间。

一、pom.xml不是下载清单

Maven使用POM（Project Object Model，项目对象模型）描述项目。pom.xml不仅声明依赖，还能记录项目坐标、构建插件等信息。

例如引入Commons IO：

<dependency>
  <groupId>commons-io</groupId>
  <artifactId>commons-io</artifactId>
  <version>2.11.0</version>
</dependency>

这三个字段不是随意填写的名字。groupId指向组织或项目群，artifactId确定组件，version指定版本。它们用于定位构件。

Maven会读取依赖对应的POM元数据，进一步判断它还需要哪些库。因此一个依赖可能带来多个jar。

二、jar包究竟存到哪里？

默认本地仓库在用户目录的.m2/repository。上面这个依赖对应的典型路径是：

.m2/repository/
└─ commons-io/
   └─ commons-io/
      └─ 2.11.0/
         ├─ commons-io-2.11.0.jar
         └─ commons-io-2.11.0.pom

路径按坐标组织，groupId中的点转成目录分隔符。

jar包含编译后的类，POM文件保存构件描述和依赖关系。本地仓库既保存jar，也缓存构件元数据。

三、中央仓库、私服，谁负责提供文件？

本地仓库保存本机已有的构件；中央仓库提供大量公开构件；企业私服则可能存放内部组件，并代理公共仓库。

假设团队部署了私服：开发电脑向私服请求Commons IO，私服如果已有缓存即可返回；没有时，私服可能再请求上游仓库并缓存结果。

这能复用缓存并集中管理内部版本。

但这里有个常见误区：Maven并不必然按照“本地→私服→中央”逐站访问。远程请求取决于仓库、镜像与更新配置。未配置私服的个人项目，也可以直接使用中央仓库。

四、为什么已经下载过，还会联网？

本地有缓存，也可能检查远程信息。对于SNAPSHOT等会变化的版本，Maven可能根据更新策略重新检查元数据；固定版本一般更容易复用已有缓存。

如果启动了离线模式，所需构件或插件在本地缺失，构建仍可能失败。

构建插件也需要解析。下载错误不一定来自业务依赖。

五、把仓库与构建过程连起来

执行：

mvn clean package

clean负责清理旧的构建输出；package会触发默认生命周期中到打包阶段为止的必要步骤，包括编译、测试等。期间Maven按需获取项目依赖和构建插件，最后在target目录产生构件。

但生成jar不意味着它一定能通过java -jar独立运行：是否有主类入口、是否打入运行时依赖，仍取决于打包配置。

想知道谁引入了某个间接依赖，可查看：

mvn dependency:tree

它能展示实际解析的依赖关系。

六、依赖报红，先定位是哪一环

看到IDEA里的红色依赖，优先检查坐标和版本，再看Maven是否重新加载。若日志提示无法获取构件，接着检查仓库地址、私服权限、网络与离线模式；如果命令行和IDEA表现不同，再执行mvn -version核对Java环境和Maven版本。

不要一开始就删除整个.m2目录。这会清掉正常缓存，迫使重新下载。

从POM声明坐标，到仓库解析与缓存，再到插件执行构建，Maven提供的不是“神奇下载按钮”，而是一套可追踪、可协作的项目构建机制。

七、最后总结：把Maven理解为一条可追踪的链

从pom.xml声明坐标，到Maven解析依赖关系，再到本地缓存和远程仓库获取构件，最后由构建插件执行编译、测试和打包，这是一条连续的工作链路。

POM回答“项目需要什么”，仓库解决“资源在哪里”，生命周期与插件决定“怎样得到构建结果”。

理解它们之间的分工，遇到报红就能判断是配置、仓库、网络、Java环境还是构建阶段出了问题，而不是一出错就删掉整个项目。

Maven的价值不仅在于自动下载jar包，更在于让Java项目的依赖来源可追踪、构建步骤可复现、团队协作有统一依据。