在多模块开发场景中，一个常见痛点：项目 Y 依赖于项目 X，当你本地修改了 X 的代码并成功执行了 mvn clean install，但编译 Y 时却报“找不到符号”。几乎每位 Java+Maven 开发者都曾遇到过这个坑。
问题的核心其实并不复杂——Maven 默认并不信任你本地的改动，它更倾向于从远程仓库（例如 Nexus、Artifactory）拉取匹配的已发布版本。即使你本地已生成最新 jar，若版本号不匹配或缓存策略未更新，Maven 就无法识别。这也就意味着，所谓的“强制使用本地版本”，本质上是让 Maven 优先从本地仓库获取最新构建产物，而非通过绕过机制采用特殊手段。
✅ 正确做法一：使用 -SNAPSHOT 版本（开发阶段首选）
将项目 X 的版本改为快照版，例如 1.0.0-SNAPSHOT，然后在项目 Y 的 pom 中显式声明该版本：
com.projectx.core projectx.core 1.0.0-SNAPSHOT
这里需要满足几个前置条件：
- 项目 X 必须已经执行过
mvn clean install，将 jar 安装到本地仓库（~/.m2/repository/）。 - 项目 Y 无需额外配置，Maven 默认每小时检查一次本地 SNAPSHOT 的更新。若希望某个修改立即生效（例如刚改完 X 就构建 Y），可加上
-U参数强制更新：mvn compile -U
需要注意的几个要点：
- SNAPSHOT 版本不能用于生产发布，仅限开发或测试环境。
- 在 CI/CD 流水线中，避免混用本地构建的 SNAPSHOT 与远程仓库中的同一版本，否则极易引发版本冲突。
- 检查你的
settings.xml，确认是否存在
✅ 正确做法二：重构为多模块项目（长期协同推荐）
如果项目 X 和 Y 属于同一业务领域，且计划长期同步演进，不必纠结版本号，直接合并到一个父项目中更为省心：
parent-pom/ ├── pom.xml ← 定义pom 及子模块 ├── projectX/ │ └── pom.xml ←jar ，版本可设为 1.0.0 └── projectY/ └── pom.xml ← 直接依赖com.projectx.core ，无需远程仓库
只需在根目录执行 mvn clean compile，Maven 便会自动按模块依赖顺序构建。项目 Y 获取的始终是项目 X 的最新编译结果，版本同步问题彻底消失。
❌ 务必避免的做法
- 不要使用版本范围语法（例如
(0.0,)、[1.0,)）：虽然语法上合法，但会导致构建行为无法重现——今天能编译通过，明天换一个 CI 环境可能就会失败。Maven 社区早已不推荐此做法。 - 不要手动复制 JAR 到 lib/ 并使用 systemPath 引入：这种做法会直接破坏 Maven 的依赖传递机制，其他模块无法继承该依赖，且 IDE 支持较差，容易引发 classpath 冲突。
总结
| 场景 | 推荐方案 | 关键操作 |
|---|---|---|
| 短期快速验证本地修改 | 使用 1.0.0-SNAPSHOT + mvn install + -U | 确保 projectX 先 install，projectY 再编译 |
| 长期协同开发 | 合并为多模块项目 | 统一生命周期管理，零配置保证一致性 |
| 生产发布前 | 升级为正式版（如 1.0.0）并部署至远程仓库 | SNAPSHOT → Release 版本需严格走发布流程 |
绕了一圈你会发现，所谓的“强制使用本地版本”，并不是依靠特殊参数或黑科技——核心就是让 Maven 信任你本地仓库中的最新产物。用 SNAPSHOT 版本匹配开发节奏，用多模块统一生命周期管理，这两条路都是在 Maven 设计框架内解决问题。可靠、可重复，才是依赖管理的正解。
