workdir 是容器内默认工作路径的锚点，应设为语义明确的稳定路径（如 /app），并配合 user 和权限最小化原则构建四层目录结构：/app（可执行文件）、/app/config（只读配置）、/app/data（状态数据）、/app/logs（日志输出）。
WORKDIR 指令本身不强制目录结构，但它决定了后续所有 RUN、COPY、CMD、ENTRYPOINT 的默认工作路径，是微服务容器内目录规范的“锚点”。用好它，能显著提升可维护性、安全性与多环境一致性。
明确服务职责，按功能分层设计根下目录
避免把代码、配置、日志、临时文件全堆在 / 或 /app 下。建议以 WORKDIR 为起点，构建清晰的四层结构：
- /app：只放编译后可执行文件或主应用包（如 JAR、binary、dist 目录），权限设为非 root 用户可读
- /app/config：挂载或 COPY 进来的配置文件（application.yml、logback.xml 等），建议只读
- /app/data：服务运行时生成的轻量级状态（如本地缓存、token store），需配合 volume 挂载或 tmpfs
- /app/logs：日志输出目录，必须可写，且应通过 logrotate 或 stdout/stderr 采集，不建议长期落盘
WORKDIR 应指向稳定、语义明确的路径
不要写 WORKDIR /tmp 或 WORKDIR /var/app 这类系统路径——它们易被覆盖、权限混乱、缺乏业务含义。推荐统一使用：
-
WORKDIR /app：最常用，简洁直观，适配 Java/Go/Node.js 多语言场景 -
WORKDIR /srv/my-service：适合需要区分多服务共存的镜像（如网关聚合镜像） - 避免嵌套过深，如
/opt/company/product/service/v1/src—— Docker 层缓存和运维排查成本高
配合 USER 和权限最小化原则落地
WORKDIR 创建的目录默认属 root，但服务不应以 root 运行。务必在 WORKDIR 后设置用户并修正目录所有权：
- 先
USER 1001再WORKDIR /app？不行——普通用户无法创建根下目录 - 正确顺序：
WORKDIR /app→RUN chown -R 1001:1001 /app && chmod 755 /app→USER 1001 - 若用非 root 用户启动，/app 下子目录（如 logs、data）需提前
mkdir -p /app/logs && chown 1001:1001 /app/logs
与多阶段构建协同，隔离构建与运行时路径
构建阶段的 WORKDIR 和运行阶段无关，但命名习惯要一致，避免混淆：
- 构建阶段可用
WORKDIR /src存放源码，编译完成后COPY --from=builder /src/dist/ /app/ - 运行阶段固定
WORKDIR /app，所有 CMD 都基于此路径，比如CMD ["./service", "--config=config/app.yaml"] - 禁止在运行镜像中保留 /src、/build 等构建残留路径，减小攻击面与镜像体积
