Dockerfile 执行 RUN cd 后，下一条 RUN 仍找不到项目文件

Docker 构建中，RUN cd /src/project 没有报错，下一条 RUN make 却找不到 Makefile；或者下一次 pwd 又回到原目录。cd 只改变当前 shell 的工作目录，不会修改后续 Dockerfile 指令使用的目录。

目录需要跨指令保持时设置 WORKDIR；只需要在一个步骤中临时切换时，把 cd 和依赖它的命令放进同一条 RUN。以下适用于 Linux 镜像，示例程序与路径须按实际项目调整。

文件留下来了，shell 状态没有留下来

下面是错误配置示例，不应按这个顺序构建：

COPY . /src/project/
RUN cd /src/project
RUN make

COPY 和构建命令写入的文件可以被后续步骤读取，但每条 RUN 的执行进程是分开的。前一个 shell 结束后，它的 cd 状态不会变成镜像的工作目录配置。若基础镜像已经设置 WORKDIR，后续步骤还可能从那个目录开始，不能一律假定是 /。

在失败指令前暂时加入：

RUN pwd && ls -la

它帮助确认本步骤实际目录。构建日志可能暴露目录名或文件清单，仅在受控环境查看，核对完成后移除。目录不对就修目录；目录正确而没有 Makefile，则检查文件是否存在、是否被构建忽略规则排除，以及生成 Makefile 的前置步骤有没有执行。

持续使用同一目录时，明确设置 WORKDIR

以下片段假设基础镜像已有项目需要的构建工具，当前构建上下文包含 Makefile：

WORKDIR /src/project
COPY . .
RUN make

WORKDIR 影响后续指令，COPY . . 的目标也因此是 /src/project。源端的 . 仍是构建上下文根，不会随 WORKDIR 改变。若不希望调整现有 COPY 的目标，可继续写绝对目标路径。

建议把首次工作目录写成绝对路径。WORKDIR project 是相对于前一个工作目录设置的，基础镜像一旦改了目录，最终路径可能随之变化。重复的 WORKDIR 指令是允许的，但应逐段确认后续 COPY、构建和启动命令受什么目录影响。

多阶段构建遇到新的 FROM 时也要检查新的基础镜像及其工作目录，不要认为上一阶段的设置自动沿用。

只在一个步骤使用时，连接命令

保持后续指令原目录不变的示例：

RUN cd /src/project && make

&& 使切换目录失败时不再执行 make。写成 cd /src/project; make，即使 cd 失败，构建也可能在错误目录执行后一个命令。目录与执行权限问题不能靠分号略过。

同一条 RUN 还可以包含多个相关步骤，但合并不是越长越好。需要复用的目录状态用 WORKDIR 表达会更清楚；必须只在当前 shell 生效的环境初始化则应与依赖它的命令放在同一个执行步骤中。

构建目录正确，运行时仍找不到文件

WORKDIR 也提供容器启动时的默认目录，但部署配置可以覆盖它。Docker 的 --workdir、Compose 的 working_dir，以及入口脚本里的 cd 都应检查。

查看实际容器配置中的目录：

docker inspect --format '{{.Config.WorkingDir}}' CONTAINER_ID

替换为目标容器 ID。这里显示的是容器配置，不保证入口脚本没有再次切换目录。若应用使用相对路径读取配置，最终进程目录和资源路径都要核对。

修正后重新构建并发布目标镜像，保存旧 Dockerfile 与镜像供回退。成功标准是失败步骤从预期目录执行、所需文件可见、构建完成，以及应用启动后的相对路径仍符合预期。仅看到 cd 返回成功不能证明后续步骤已经使用该目录。