workdir 的核心作用是为后续指令设置默认工作目录，自动创建多级目录、支持 env 动态路径、可覆盖继承，提升构建可读性与运行时一致性。
在 Dockerfile 中使用 WORKDIR 的核心作用，是为后续的 RUN、COPY、ADD 和 CMD 等指令设置默认工作目录，从而避免反复写冗长的绝对路径（比如 /app/src/main），让构建逻辑更清晰、可读性更强、维护成本更低。
用 WORKDIR 替代重复的 cd + 绝对路径
不使用 WORKDIR 时，你可能这样写：
RUN mkdir -p /app/src && cd /app/src && npm install COPY ./src /app/src RUN cd /app/src && npm run build CMD ["node", "/app/src/dist/index.js"]
问题明显：路径重复、易出错、难修改。换成 WORKDIR 后，简洁又可靠：
WORKDIR /app/src RUN npm install COPY ./src . RUN npm run build CMD ["node", "dist/index.js"]
所有相对路径都基于 /app/src 解析，COPY . 就是复制到当前工作目录，dist/index.js 也自动落在 /app/src/dist/ 下。
支持多层级目录自动创建
WORKDIR 会自动创建指定路径（包括中间不存在的父目录），无需提前 RUN mkdir -p：
-
WORKDIR /a/b/c→ 如果/a和/a/b不存在，Docker 会一并创建 - 等价于手动执行
mkdir -p /a/b/c，但更简洁、无副作用 - 适合快速切换到深层项目结构，比如
WORKDIR /workspace/backend/api
配合 ENV 实现路径动态化（提升复用性）
如果镜像要适配不同环境或项目名，可结合 ENV 定义基础路径，再由 WORKDIR 引用：
ENV APP_HOME=/opt/myapp WORKDIR $APP_HOME/src COPY . . RUN make build
这样改路径只需调整 ENV 行，所有后续指令自动生效；也方便通过 docker build --build-arg 动态传入值。
注意 WORKDIR 的继承性和覆盖行为
每个 WORKDIR 指令都会覆盖前一个，且影响后续所有层（包括运行容器时的默认目录）：
- 子镜像会继承父镜像最后设置的
WORKDIR - 可以在同一 Dockerfile 中多次使用，例如先切到构建目录，再切到部署目录：
WORKDIR /build<br>RUN ./configure && make<br>WORKDIR /app<br>COPY --from=0 /build/bin/app .
- 容器启动时，
WORKDIR也会作为cmd或entrypoint的执行起点，所以它不只是构建优化，还影响运行时行为
