WORKDIR 是 Docker 官方唯一推荐的设置容器默认工作目录的方式，用于 Dockerfile 中固化路径；-w 仅运行时临时覆盖；VOLUME 与工作目录无关；Docker Desktop GUI 不提供工作目录配置。
WORKDIR 是唯一可靠、被 Docker 官方明确支持的设置容器默认工作目录的方式。其他手段（比如在 CMD 里加 cd、用 docker exec -w 临时指定）只影响单次执行，不改变容器启动时的默认路径。
用 WORKDIR 在 Dockerfile 中固化工作目录
这是最常用也最推荐的做法，适用于你控制镜像构建过程的场景。
-
WORKDIR指令会创建目录（如果不存在），并设为后续所有指令（RUN、CMD、ENTRYPOINT）的默认执行路径 - 它支持相对路径：比如前一行是
WORKDIR /app，下一行写WORKDIR src，最终路径就是/app/src - 多个
WORKDIR会叠加，但不建议嵌套太深，容易在调试时搞不清当前路径 - 示例：
FROM alpine:latest WORKDIR /opt/myapp COPY . . RUN ls -l # 这里 pwd 就是 /opt/myapp CMD ["sh"]
构建后运行容器：docker run -it myimage，进去就直接在 /opt/myapp，不是 /。
运行时用 -w 覆盖工作目录（仅限 docker run 或 exec）
当你无法修改镜像（比如用的是官方 nginx、redis 镜像），又想临时让容器从某个目录启动，可以用 -w 参数。
-
docker run -w /data -it ubuntu:22.04→ 启动后自动 cd 到/data（即使镜像没建这个目录，Docker 也会尝试创建） -
docker exec -w /app -it mycontainer ls→ 只对这次exec生效，不影响下次 - 注意：
-w不会改变镜像本身的WORKDIR，也不会影响ENTRYPOINT的解析逻辑（比如它仍会按原WORKDIR解析相对路径）
别误用 VOLUME 当工作目录设置手段
VOLUME 指令和工作目录无关，它只声明一个挂载点，用于数据持久化。常见误解是以为写了 VOLUME /app 就能让容器默认进 /app——不会。
-
VOLUME /app只表示“这个路径将来可能被挂载”，Docker 会自动初始化一个匿名卷到该路径，但容器启动时 pwd 仍是镜像定义的WORKDIR或/ - 如果你同时写了
WORKDIR /app和VOLUME /app，那只是巧合路径重合，二者职责完全独立 - 真正要挂载宿主机目录到容器内某路径，得用
-v或--mount，而不是VOLUME
Docker Desktop GUI 里没有“设置工作目录”的开关
Docker Desktop 的图形界面（Run dialog）里可以填 Command、Environment variables、Volumes，但**没有“Working directory”输入框**。它不提供对 WORKDIR 或 -w 的可视化配置。
- 你看到的 “Volumes” 是用来做目录挂载的，不是改工作目录
- 想用 GUI 启动时指定工作目录，唯一办法是把命令写死，比如填
sh -c "cd /mywork && exec bash"——但这属于 hack，不可靠，且破坏了镜像原本的入口逻辑 - 真要稳定控制，必须回到 Dockerfile 或
docker run -w
WORKDIR 是构建时决定的，-w 是运行时覆盖的，两者配合才完整。很多人卡在“为什么 GUI 里找不到设置项”，其实是因为 Docker Desktop 本就不暴露这个底层概念——它默认信任镜像作者已经用 WORKDIR 设好了。
