容器内程序运行目录设计应以可维护性、安全性与构建效率为核心，推荐使用/app或/opt/app作为显式声明的workdir，按职责分离为/app/src、/app/config、/app/data三层结构，并配合user、权限控制及精准copy实现最小权限与缓存优化。
容器内程序的运行目录设计，本质是围绕可维护性、安全性与构建效率展开的结构化约定。关键不在于“多深多复杂”，而在于层次清晰、职责分明、与 Docker 的分层机制协同。
明确基础工作目录（WORKDIR）
所有后续操作都应基于一个统一、显式声明的工作目录。推荐使用 /app 或 /opt/app 这类语义明确且非系统路径的目录，避免使用 /、/usr 等易与基础镜像冲突的位置。
- 用 WORKDIR /app 开头，Docker 会自动创建该目录并设为后续指令默认路径
- 不要依赖 RUN mkdir 后再 CMD cd —— 容器启动时不会继承 shell 的当前目录，CMD 中的相对路径会失效
- 若需多级结构（如 src/bin/config），可在 WORKDIR 后用 RUN mkdir -p src bin config 显式创建，或直接在 COPY 时由目标路径隐式生成
按职责分离子目录结构
目录划分应反映程序生命周期中的不同角色，而非开发机上的随意组织。常见且实用的三层结构如下：
- /app/src：存放源代码或编译产物（如 Python 的 .py 文件、Go 的二进制文件）
- /app/config：仅放配置文件（如 config.yaml、.env），便于通过 volume 挂载替换
- /app/data：声明为 VOLUME 的挂载点，用于持久化日志、缓存或用户数据
不建议将依赖安装路径（如 Python 的 site-packages）或构建中间产物混入这些目录——它们应由基础镜像或 RUN 指令管理，不属于应用逻辑目录树。
控制文件复制范围与时机
COPY 指令直接影响镜像体积和构建缓存效率，目录设计必须适配这一机制：
- 先 COPY requirements.txt /app/（或 package.json），再 RUN pip install，最后 COPY . /app/ —— 让依赖安装层缓存更稳定
- 用 .dockerignore 排除本地开发文件（如 __pycache__、.git、node_modules），防止无关内容污染构建上下文和最终镜像
- 避免 COPY ./ /app/ 这种粗粒度操作；优先 COPY src/ /app/src/、COPY config/ /app/config/，保持目录映射精准
权限与用户视角下的目录安全
运行目录不仅是路径，更是权限边界的起点：
- 在 WORKDIR 之后、COPY 之前，用 USER 切换到非 root 用户（如 useradd -r app && USER app）
- 确保该用户对 /app 及其子目录有读写执行权限（RUN chown -R app:app /app）
- 敏感目录如 /app/config 可额外设置 RUN chmod 600 /app/config/*.yaml，限制配置文件访问
目录结构本身不提供安全，但配合 USER 和权限指令，能让最小权限原则真正落地。
