今天我们来探讨一个在 Windows 环境下使用 Maven 时经常遇到的典型问题：由于错误地使用了 install:install-file 命令，导致子模块在解析依赖时无法找到父 POM。本文将深入分析根本原因，并给出符合 Maven 标准规范的最佳解决方案——核心原则是避免手动干预本地仓库路径，完全信任并依赖默认的 .m2 本地仓库机制。
在 Windows 操作系统中，Maven 默认会将所有构建产物（包括父 POM 和子模块）自动安装到当前用户主目录下的本地仓库中：C:\Users\<用户名>\.m2\repository。这个目录是 Maven 依赖解析的核心枢纽，无论你在哪个模块下执行 mvn install 命令，构建产物都会被写入该位置；后续其他模块进行构建时，也会默认从该目录读取所需的依赖。
问题是如何产生的呢？假设你在 demo 项目中通过 mvn install:install-file 将 math-util-1.0-SNAPSHOT.jar 手动安装到了自定义路径 ./lib 下，并在 POM 中配置了 file://${project.basedir}/lib。表面上看这样配置似乎合理，但实际上却绕过了 Maven 的依赖传递机制，并会引发一系列严重后果：
math-util-1.0-SNAPSHOT.jar的 pom.xml（由 install-file 自动生成）中明确声明了父 POM：com.ja vi parent-util 1.0-SNAPSHOT - 当 Maven 解析
math-util依赖时，会递归查找其父 POM——即 com.ja vi:parent-util:pom:1.0-SNAPSHOT； - 问题的关键在于：这个父 POM 根本不存在于 ./lib 目录中。因为
install-file仅处理你指定的那个 JAR 文件，不会自动处理该 JAR 所依赖的 parent 信息或其他关联组件； - 此外，Windows 系统下
file://协议对路径解析非常敏感，反斜杠、空格、中文字符等都可能引发解析异常，即使你尝试手动补充父 POM，也很难保证稳定识别； - 相比之下，在 Ubuntu 或 macOS 系统中使用
file://协议容错性更高，有时能够“碰巧”成功——但这本质上是用平台差异掩盖了不规范的实践方式。
正确的做法是什么？回归 Maven 的标准生命周期，彻底摆脱手动 install-file 的操作习惯。
在 parent-util 根目录下执行一次完整的标准安装：
cd /path/to/parent-utilmvn clean install
这条命令完成了三个关键步骤：
- 首先将
parent-util-1.0-SNAPSHOT.pom安装到~/.m2/repository/com/ja vi/parent-util/1.0-SNAPSHOT/ - 然后将
math-util-1.0-SNAPSHOT.jar及其 pom.xml（其中已正确引用父 POM）安装到对应的标准路径 - 通过这种方式，父子依赖关系在本地仓库中被完整且正确地建立起来，Maven 可以准确检索到每一个组件。
- 首先将
删除 demo 项目中所有自定义仓库配置：
demo/pom.xml 中仅保留标准依赖声明：
com.ja vi math-util 1.0-SNAPSHOT Maven 会自动从
~/.m2/repository中定位到math-util，然后沿着它的 pom.xml 找到已经正确安装的parent-util，完成整个依赖树解析。Windows 环境下需要特别注意的验证与清理步骤：
- 确保 demo 项目在 IDE（如 IntelliJ IDEA）中没有启用“离线模式”；
- 如果之前构建失败，本地缓存中可能残留了干扰信息，建议执行：
mvn clean compile -U # -U 参数强制更新所有快照依赖
- 如果仍然报错，请检查
~/.m2/repository/com/ja vi/目录下是否存在parent-util/1.0-SNAPSHOT/parent-util-1.0-SNAPSHOT.pom文件——如果该文件缺失，说明 parent-util 本身就没有安装成功，需要重新执行第一步。
⚠️ 以下几个关键点必须牢记：
- 永远不要对多模块项目中的子模块单独使用 install:install-file：这种做法会破坏 Maven 的模块化构建逻辑，导致 parent-child 依赖关系被彻底切断；
仅在父 POM 与当前 POM 在物理文件路径上相邻时才生效 （例如../pom.xml），对于已经安装到.m2仓库中的 snapshot 依赖无效；- Windows 路径中如果包含空格或中文字符，
file://协议极易出现解析故障，而~/.m2是 Maven 官方反复测试验证的安全路径，具有最佳的兼容性； - 如果希望将
math-util分发给外部团队使用，正确的做法是将其发布到 Nexus 或 Artifactory 等远程私有仓库，而不是直接传递 JAR 文件——这才是企业级依赖管理的标准实践。
按照上述流程完整执行一遍后，在 demo 项目中运行 mvn clean install 应该能够稳定成功，并且在跨平台环境下表现一致。归根结底，Maven 的强大之处正源于其“约定优于配置”的设计理念——尊重默认规则，才能游刃有余地应对各种构建场景。
