Java代码编译差异：mvn verify与mvn compile行为不一致原因求解

直接回答短版问题：mvn compile和mvn verify本身触发的编译阶段逻辑完全一致，你遇到的差异是多模块项目的反应堆依赖解析规则导致的，和compile、verify的编译逻辑无关。

• Maven在单次构建会话（即一次mvn命令调用）中，默认对普通多模块依赖会优先使用当前反应堆的编译产物，但如果你的plugins模块是maven-plugin类型（从模块名推测大概率是），Maven为了保证插件构建的稳定性，默认只会从本地/远程仓库拉取依赖的已发布版本，不会直接使用当前反应堆中server模块刚编译出来、还没install到本地仓库的类。你执行的mvn -DskipTests compile verify属于单次构建会话，因此同样触发该限制，也会出现找不到符号的报错。
• 分两次执行命令成功的原因：第一次执行mvn compile已经把server模块的最新代码编译到了其target/classes目录，第二次执行mvn verify是独立的新构建会话，Maven检测到server模块的代码没有变更，会直接将已有的target/classes目录加入依赖classpath，不需要从仓库拉取jar包，因此可以正常找到新增方法。
• 执行mvn install能成功的原因也很明确：install会把server模块的最新构建产物上传到本地仓库，plugins模块构建时从本地仓库就能拉到包含新增方法的版本。

• 执行verify命令时添加反应堆参数，强制模块间依赖使用本地编译产物：

mvn -DskipTests -Dmaven.reactor.useModuleOutput=true verify

该参数对Maven 3.3+版本生效，会让Maven在构建时直接引用同项目内其他模块的target/classes目录下的类，不需要依赖已install的jar包。

• 如果你的plugins模块确实是Maven插件类型，也可以调整构建流程，将插件的集成测试拆分到独立的构建会话中，避免同一会话下的依赖解析限制。
• 额外检查plugins模块的pom.xml中对server的依赖配置，确保没有强制指定<type>jar</type>或硬编码固定版本号，保证依赖是对项目内模块的引用，而非外部仓库的artifact。

内容的提问来源于stack exchange，提问作者Dhaval D