本文详解 docker 多阶段构建中因路径错误和冗余指令导致的 jar 复制失败问题，提供可直接使用的修复方案，确保 spring boot 应用能正确解包并运行。
本文详解 docker 多阶段构建中因路径错误和冗余指令导致的 jar 复制失败问题，提供可直接使用的修复方案，确保 spring boot 应用能正确解包并运行。
在使用多阶段 Dockerfile 构建 Spring Boot 应用时，一个常见错误是混淆“构建阶段内复制”与“主机上下文复制”，从而触发类似 lstat ... no such file or directory 的构建失败。原始 Dockerfile 中的关键问题在于：
- 冗余且危险的 COPY ${JAR_FILE} application.jar 指令：该行试图从本地主机构建上下文（即 docker build 命令执行目录下的 target/*.jar）复制 JAR 文件。但若未提前在宿主机执行 mvn clean install，该路径根本不存在，导致构建中断；
- 路径不一致与命名不匹配：Maven 默认生成的 JAR 文件名为 <artifactId>-<version>.jar（如 up-user-service-0.0.1.jar），而后续 java -Djarmode=layertools -jar application.jar extract 要求文件必须命名为 application.jar，否则解包失败；
- 缺失 WORKDIR 导致路径混乱：第二阶段（builder）未设置工作目录，COPY --from=maven_builder ... 后的 COPY ${JAR_FILE} ... 实际尝试从宿主机相对路径复制，加剧了路径不可控性。
✅ 正确做法是完全依赖构建阶段产物，杜绝主机依赖，并统一 JAR 命名。以下是优化后的完整 Dockerfile：
# 第一阶段：Maven 构建 FROM maven:3.8.3-openjdk-17 AS maven_builder WORKDIR /app COPY up-user-service/pom.xml . COPY up-user-service/src ./src RUN mvn clean package -DskipTests # 关键修复：重命名生成的 JAR 为 application.jar RUN mv target/*.jar target/application.jar # 第二阶段：解包 Spring Boot 分层结构 FROM openjdk:17-jdk-alpine AS builder WORKDIR /app # 直接从上一阶段复制已重命名的 JAR COPY --from=maven_builder /app/target/application.jar . RUN java -Djarmode=layertools -jar application.jar extract # 最终运行阶段 FROM openjdk:17-jdk-alpine WORKDIR /app # 按 layer 顺序复制解包内容（注意路径需与 extract 输出一致） COPY --from=builder /app/dependencies/ ./ COPY --from=builder /app/snapshot-dependencies/ ./ COPY --from=builder /app/spring-boot-loader/ ./ COPY --from=builder /app/application/ ./ ENTRYPOINT ["java", "org.springframework.boot.loader.JarLauncher"]
? 关键注意事项：
- ✅ mvn clean package 比 install 更轻量，避免将构件安装到本地仓库（非必需）；
- ✅ 所有 COPY --from= 必须使用绝对路径（如 /app/target/application.jar），且目标路径需与 WORKDIR 匹配；
- ✅ java -Djarmode=layertools -jar ... extract 会在当前目录生成 dependencies/、spring-boot-loader/ 等子目录，因此后续 COPY --from=builder 的源路径必须精确对应（例如 /app/dependencies/）；
- ❌ 切勿保留 ARG JAR_FILE=... 和 COPY ${JAR_FILE} ... —— 它们引入主机耦合，违背多阶段构建的设计初衷；
- ? 调试技巧：临时添加 RUN ls -la /app/target/ 在 mvn package 后，可确认 JAR 是否生成及命名是否正确（Docker BuildKit 默认隐藏中间输出，但该命令仍会打印日志）。
通过以上调整，构建流程完全隔离于宿主机环境，稳定复现生产部署行为，同时满足 Spring Boot 分层打包（Layered JAR）的最佳实践。
