1. 问题背景项目结构如下|–Module1|-----service|-----pom.xml|–Module2|-----service|-----pom.xml|–pom.xml在java项目分为不同的模块Module1和Module2分别有不同的pom.xml文件并且最外层有一个主pom.xml分为两个小组分别开发Module1和Module2并且分别部署为不同的微服务A和B。于是微服务A有Module1的最新代码和Module2的旧代码微服务B有Module2的最新代码和Module1的旧代码。现在微服务A的Module1需要Module2的最新代码微服务B的Module2打了一个jar包版本号为0.0.0.5版本。现在只修改微服务A的Module1的pom.xml文件中Module2版本号为0.0.0.5Module2的pom.xml保持为原来的版本号0.0.0.4测试无问题。修改微服务A的Module1的pom.xml文件中Module2版本号为0.0.0.5在此基础上主pom.xml也改为0.0.0.5时Module2原来的pom.xml保持为原来的版本号0.0.0.4测试无问题。最后修改微服务A的Module1的pom.xml文件中Module2版本号为0.0.0.5在此基础上主pom.xml也改为0.0.0.5时微服务A的Module2自身的pom.xml文件改为0.0.0.5时。此时程序就会编译不通过报错。下面我们探索以上3种方式修改后产生不同结果的原因。2. 分析这是一个非常经典且具体的 Maven 多模块构建与依赖解析冲突问题。初始状态正常Module1 (微服务A): 代码最新依赖 Module2 版本 0.0.0.4。Module2 (本地): 代码旧版本 0.0.0.4。远程仓库: 有微服务 B 发布的真实 Module2-0.0.0.5.jar (含新代码)。行为: Module1 使用本地的 Module2 (0.0.0.4) 编译一切正常因为此时还没用到新功能。第一步修改正常操作: 仅修改 Module1/pom.xml将依赖指向 0.0.0.5。Maven 行为:Maven 检查本地工程发现本地的 Module2 版本还是 0.0.0.4不匹配。Maven 转向远程仓库查找 0.0.0.5。成功下载微服务 B 发布的真实 Module2-0.0.0.5.jar。结果: Module1 编译时使用的是远程的真实新代码所以测试通过。第二步修改正常操作: 在第一步修改基础上修改 主pom.xml将版本统一定义为 0.0.0.5。Maven 行为: 逻辑同上。只要本地 Module2 的自身版本号没变Maven 依然会去远程仓库找 0.0.0.5。结果: 依然使用远程真实 Jar 包测试通过。第三步修改报错操作: 在第二步修改基础上修改 Module2/pom.xml将其 从 0.0.0.4 改为 0.0.0.5。关键点: 此时你并没有拉取微服务 B 的最新代码到你的本地 Module2 目录中你的本地 Module2 代码依然是旧的。Maven 行为变化:Maven 开始构建反应堆Reactor。它发现当前工程中有一个模块 Module2其 pom.xml 声明的版本正是 0.0.0.5。优先级规则: Maven 优先使用当前反应堆中的模块而不是去远程仓库下载同名同版本的 Jar 包。后果: Module1 在编译时依赖解析指向了本地的 Module2。编译失败原因:Module1 的最新代码中调用了 Module2 在 0.0.0.5 版本中才有的新方法/新类。但是Maven 实际提供给编译器的是你本地那个旧代码的 Module2虽然它现在叫 0.0.0.5。编译器报错:cannot find symbol (找不到方法/类) 或 method not found。因为那时本地 Module2 的版本号是 0.0.0.4与 Module1 需求的 0.0.0.5 不匹配。Maven 被迫忽略本地模块转而去远程仓库下载了正确的、包含新代码的 Jar 包。一旦把本地 Module2 的版本号改成了 0.0.0.5就会“欺骗”了 Maven让Maven以为本地的旧代码就是它需要的新版本从而阻断了它去远程获取真实代码的路径。3. 解决方案方案 A不要修改本地 Module2 的版本号推荐如果你只是想在 Module1 中测试对 Module2 新版本的依赖绝对不要修改本地 Module2 的 pom.xml 版本号。保持本地 Module2的pom.xml 版本为 0.0.0.4。保持 Module1 和 主pom 依赖版本为 0.0.0.5。这样 Maven 会始终从远程仓库拉取微服务 B 发布的真实 0.0.0.5 Jar 包。注意这要求你不能在本地同时修改 Module2 的代码。如果需要联调修改 Module2 的代码请看方案 B。方案 B同步最新代码如果需要本地联调如果你确实需要修改 Module2 的代码并让 Module1 引用从 Git 拉取微服务 B 团队的最新代码合并到你本地的 Module2 目录中。确保本地 Module2 的代码确实包含了 0.0.0.5 所需的所有新特性。此时再将 Module2的pom.xml 改为 0.0.0.5。这样本地反应堆构建出来的 0.0.0.5 才是真实的、包含新代码的编译就能通过。4. 结论报错的根本原因是Maven 的反应堆Reactor构建机制优先使用了本地修改过版本号但代码未更新的 Module2导致编译时找不到新代码中定义的方法或类。把本地 Module2 的 pom.xml 版本号改为 0.0.0.5 时Maven 认为“这个模块就在当前工程中且版本匹配”于是不再去远程仓库下载微服务 B 团队发布的那个包含新代码的真实 0.0.0.5 Jar 包而是直接使用本地这个只有旧代码、却有不匹配的新版本号的 Module2 进行编译。报错的原因主要是本地代码滞后于版本号。现象: 改了版本号 - Maven 优先用本地旧代码 - 编译找不到新方法 - 报错。修复方案:不要修改本地 Module2 的版本号使Maven继续依赖远程 Jar包。同步本地 Module2 的最新代码使之名副其实代码与0.0.0.5版本号匹配一致。