workdir指令用于设置容器内工作目录，影响run、cmd、entrypoint等后续指令执行路径，自动创建目录并确保路径可写、与挂载对齐，是避免路径混乱和权限错误的关键。
合理设置 Dockerfile 的默认工作路径，核心是用好 WORKDIR 指令——它不只影响构建阶段的命令执行位置，更决定容器运行后 docker exec 的初始目录。设得不当，轻则命令报错、脚本找不到文件，重则引发权限或挂载路径错位问题。
明确用途再选路径
不要盲目写 WORKDIR /app。先想清楚这个目录要承载什么：
- 如果是 Web 应用（如 Node.js、Python Flask），选
/app或/var/www更符合惯例，也方便后续挂载宿主机代码 - 如果只是临时运行工具（如调试用的 busybox），用
/tmp或/root即可，避免污染长期路径 - 若需兼容系统服务规范（如 systemd 容器化），参考对应发行版约定，比如 Debian/Ubuntu 常用
/srv
路径需可写且与挂载对齐
WORKDIR 设的路径，必须确保容器内进程有写权限，并与运行时挂载保持一致：
- 避免设在
/usr、/bin等只读系统目录下，否则npm install或pip install会失败 - 如果计划用
-v /host/project:/app挂载代码，那 WORKDIR 就必须是/app，否则挂载后进不去目标目录 - 多层嵌套路径（如
/opt/myapp/src）虽可行，但增加理解成本，一般两段以内更清晰
配合 CMD/ENTRYPOINT 使用
WORKDIR 的效果要在启动命令中体现出来。例如：
-
WORKDIR /app+CMD ["node", "index.js"]→ node 进程会在/app下执行，自动读取该目录下的index.js -
WORKDIR /data+ENTRYPOINT ["/entrypoint.sh"]→ 脚本启动时当前路径就是/data，方便读写配置或日志 - 若 ENTRYPOINT 是二进制绝对路径（如
ENTRYPOINT ["/usr/local/bin/myapp"]），WORKDIR 不影响其执行位置，但 shell 类命令仍受其约束
验证是否生效
构建镜像后别急着跑，快速确认 WORKDIR 是否按预期写入：
- 运行容器：
docker run -d --name test-img your-image sleep infinity - 查配置：
docker inspect test-img --format='{{.Config.WorkingDir}}'，输出应为设定路径 - 进容器验证：
docker exec -it test-img pwd，结果应与上一步一致
