maven 在执行任何构建阶段前就已解析并锁定所有依赖，因此在 validate 阶段用 maven-install-plugin 安装本地 jar 无法被后续编译或打包阶段识别——依赖解析是预执行、不可变的前置过程。
maven 在执行任何构建阶段前就已解析并锁定所有依赖，因此在 validate 阶段用 maven-install-plugin 安装本地 jar 无法被后续编译或打包阶段识别——依赖解析是预执行、不可变的前置过程。
这是 Maven 构建模型中一个常被误解但至关重要的设计原则：依赖解析（Dependency Resolution）发生在生命周期执行之前（pre-execution），而非按 phase 顺序逐个进行。当你运行 mvn package 时，Maven 并非从 validate → compile → package 线性推进并动态更新依赖图；而是先完成以下三步：
-
读取 pom.xml（含
块）； - 解析依赖树：递归定位所有声明依赖的坐标（groupId:artifactId:version），检查本地仓库（.m2/repository）是否存在，若缺失则尝试远程仓库（如 Central）；
- 冻结依赖图：一旦解析完成，整个构建过程将严格基于该快照运行——后续任何插件（包括 maven-install-plugin:install-file）对本地仓库的修改，均不会触发依赖重解析。
因此，mvn validate 成功仅说明 install-file 执行无误；mvn compile 表面成功，往往是因为你此前手动安装过该 JAR，或编译阶段未实际引用该依赖（例如仅在 test scope 或 runtime 中使用）；而 mvn package 失败，则清晰暴露了依赖在解析期即未命中——Maven 在进入 validate 前早已报错或跳过，根本不会等到 install-file 运行。
✅ 正确解法：将依赖安装移出构建流程，作为预置步骤
推荐采用以下任一方式：
-
CI/CD 脚本中显式安装（推荐）：
# 在 mvn package 前执行 mvn install:install-file \ -Dfile=./lib/my-local-lib-1.0.jar \ -DgroupId=com.example \ -DartifactId=my-local-lib \ -Dversion=1.0 \ -Dpackaging=jar mvn package
-
使用 dependency:copy + systemPath（仅限单模块、不推荐用于发布）：
<dependency> <groupId>com.example</groupId> <artifactId>my-local-lib</artifactId> <version>1.0</version> <scope>system</scope> <systemPath>${project.basedir}/lib/my-local-lib-1.0.jar</systemPath> </dependency>⚠️ 注意：system scope 依赖不会被打包进 fat jar（除非额外配置 maven-shade-plugin 显式包含），且无法传递给下游模块，仅作临时绕过方案。
改用 maven-deploy-plugin 发布至私有仓库（企业级最佳实践）：
将本地 JAR 部署到 Nexus/Artifactory，再在 pom.xml 中配置，实现标准化、可复现、可审计的依赖管理。
? 总结：Maven 的“阶段驱动”是表象，其底层是“依赖先行”的静态解析模型。试图在构建中动态注入依赖，违背了 Maven 的确定性设计哲学。自动化应聚焦于构建前准备（Pre-build Setup），而非构建内修补（In-build Patch）。
