WORKDIR 是 Dockerfile 中定义后续所有指令默认执行目录的关键指令，影响构建（COPY、RUN）和运行（CMD、ENTRYPOINT）阶段，推荐使用语义清晰的绝对路径（如 /app）作为统一根目录，按模块显式切换子目录（如 /app/service-a），避免 RUN cd 等不可靠操作，确保路径行为可预期、易维护。
在多模块项目中，用好 WORKDIR 是让 Dockerfile 更清晰、可维护的关键。它不只影响构建时的路径，还决定运行时命令（如 CMD、ENTRYPOINT）的默认上下文，尤其当多个模块各自有源码、配置、启动脚本时，统一工作目录能避免路径混乱和硬编码。
明确 WORKDIR 的作用范围
`WORKDIR` 设置的是后续所有指令（COPY、RUN、CMD、ENTRYPOINT）的默认执行目录。它不是“切换到某处再复制”，而是为整个构建阶段和运行阶段定义一个基准路径。
关键点：
- 每个 `WORKDIR` 指令都会覆盖前一个，且对后续所有层生效
- 路径可以是绝对路径（推荐），也可以是相对路径（基于上一个 `WORKDIR`）
- 容器启动后，`docker run` 执行的命令也默认在此目录下运行
为多模块设计统一根路径
假设项目结构如下：
my-app/
├── common/
├── service-a/
│ ├── src/
│ └── pom.xml
├── service-b/
│ ├── src/
│ └── pom.xml
└── docker/
└── base.Dockerfile
建议在基础镜像或顶层 Dockerfile 中设置一个固定根路径，例如：
WORKDIR /app
这样所有模块的构建和运行都以 `/app` 为锚点，后续操作更可控。不要写成 `WORKDIR ./service-a` 或 `WORKDIR ../` 这类易出错的相对路径。
按模块分层时复用 WORKDIR，避免重复切换
如果为每个模块单独构建镜像（如 `service-a:latest`、`service-b:latest`），可在各自的 Dockerfile 中先继承统一基础，再进入对应子目录：
FROM my-base:1.0 WORKDIR /app COPY service-a/ ./service-a/ WORKDIR /app/service-a # 明确进入模块目录 RUN ./mvnw clean package -DskipTests CMD ["java", "-jar", "target/service-a.jar"]
注意：
- `COPY service-a/ ./service-a/` 基于 `/app` 目录完成
- 第二个 `WORKDIR` 不是必须，但显式声明能防止 `RUN` 或 `CMD` 因路径错位失败
- 所有路径（如 `target/`、`config.yml`）都相对于 `/app/service-a`，逻辑清晰
配合 COPY 和 RUN 保持路径语义一致
一旦设定了 `WORKDIR`，就应让 `COPY` 和 `RUN` 与之对齐。常见反例：
WORKDIR /app COPY . . RUN cd service-a && ./build.sh # ❌ 隐式切换，难追踪、不可读
推荐写法：
WORKDIR /app COPY service-a/ ./service-a/ WORKDIR /app/service-a RUN ./build.sh # ✅ 路径意图明确，日志和调试更直观
对于需跨模块引用的资源（如 `common/` 模块），可用相对路径或符号链接，但优先通过构建工具（Maven 多模块、Gradle composite build）解决依赖，而非 Docker 层面拼路径。
不复杂但容易忽略。核心就是：选一个干净的绝对路径作根，模块内再进子目录，所有指令都基于当前 WORKDIR 展开。这样无论镜像怎么拆分、CI 怎么调度，路径行为始终可预期。
