workdir必须使用从/开始的绝对路径，为后续所有指令设定执行上下文；推荐遵循fhs规范选择语义化路径如/app、/var/www等，避免/tmp等临时路径，多次使用时宜保持绝对路径独立清晰。
WORKDIR 是 Dockerfile 中控制路径逻辑的核心指令，它不只影响构建过程，更直接决定容器运行时的默认位置。用对了，能避免大量路径错误；用错了，轻则文件写错位置，重则命令执行失败。
必须用绝对路径，且从 / 开始
Docker 容器没有“当前目录”的概念，WORKDIR 的作用是为后续所有指令（RUN、CMD、COPY、ADD、ENTRYPOINT）设定一个确定的执行上下文。这个上下文必须是绝对路径，否则构建会直接报错：“WORKDIR requires an absolute path”。
- ✅ 正确写法：
WORKDIR /app、WORKDIR /var/www/html、WORKDIR /opt/my-service - ❌ 错误写法：
WORKDIR app（缺/）、WORKDIR ./src（相对路径）、WORKDIR ../data（上级路径不允许） - ⚠️ 变量需谨慎：
WORKDIR $HOME/app不推荐——$HOME在构建阶段可能未定义或为空，导致路径非法；如需动态路径，应配合ARG显式传入并确保以/开头，例如：ARG APP_ROOT=/srv/myapp+WORKDIR ${APP_ROOT}
路径设计要兼顾语义与规范
选什么路径不是随意的，它关系到可读性、协作一致性和运维友好度。优先采用 Linux FHS（Filesystem Hierarchy Standard）约定，让路径本身传达用途。
-
/app：通用应用主目录，适合大多数微服务或 CLI 工具 -
/var/www：Web 类服务（如 Nginx、PHP 应用）的标准存放位置 -
/opt/<name></name>：第三方独立软件包，比如/opt/prometheus -
/srv/<service></service>：面向服务的数据/配置根目录，适合多服务共存场景（如网关镜像） - 避免使用
/tmp、/root、/home等临时或特权路径——除非有明确理由（如调试临时写入），否则易引发权限或生命周期问题
多次 WORKDIR 是允许的，但要注意叠加逻辑
同一个 Dockerfile 中可以多次使用 WORKDIR，每次都会切换后续指令的执行上下文。如果后一次用了相对路径，它会基于前一次的绝对路径拼接。
- 例如：
WORKDIR /a→WORKDIR b→WORKDIR c，最终效果等价于WORKDIR /a/b/c - 这种写法虽合法，但容易造成路径嵌套过深（如
/opt/company/product/v2/src），增加层缓存失效风险和排查难度，不建议在生产镜像中滥用 - 更清晰的做法是：始终使用完整绝对路径，保持每条 WORKDIR 指令语义独立、意图明确
WORKDIR 影响容器启动和 exec 行为
镜像构建时设的 WORKDIR，会固化为镜像元数据中的 WorkingDir 字段，直接影响容器行为：
- 容器启动后，
CMD或ENTRYPOINT默认在此目录下执行 - 执行
docker exec -it <container> sh</container>时，shell 默认打开的位置就是该 WORKDIR - 可通过
docker inspect <container> | grep WorkingDir</container>查看实际值 - 若需临时覆盖，可在 exec 时用
-w参数指定，例如：docker exec -it -w /tmp myapp ls
