核心三点：构建时用copy --chown设文件归属（如--chown=appuser:appuser），运行时用--user指定uid/gid（如--user 1001:1001），挂载前对齐宿主机与容器uid/gid，避免permission denied。
核心就三点：镜像构建时设好文件归属，运行时指定用户身份，挂载卷前对齐 UID/GID。不写全容易出 Permission Denied。
构建阶段用 COPY --chown 固定属主
默认 COPY 的文件都归 root，非 root 用户启动容器时会读不了、写不了。直接在复制时把所有权交给目标用户：
- COPY --chown=appuser:appuser ./src /app —— 把代码复制过去就属于 appuser
- COPY --chown=www-data:www-data config/nginx.conf /etc/nginx/nginx.conf —— 配置文件也按服务用户设好
- 配合 RUN adduser -D appuser 先建用户，再 --chown，再 USER appuser
运行时用 --user 显式声明身份
即使镜像里写了 USER，启动时仍可覆盖。强制以确定 UID/GID 运行，避免依赖镜像内定义：
- docker run --user 1001:1001 myapp —— 容器内进程 UID=1001、GID=1001
- docker run -v /host/data:/data --user 1001:1001 myapp —— 挂卷时需确保宿主机 /host/data 目录对 UID 1001 可读写
- 如果宿主机没有 UID 1001 用户，只要目录权限是 drwxr-xr-x 1001 1001 或更宽松（如 755 + 所属组包含 GID 1001），就能访问
挂载卷前统一 UID/GID 规划
宿主机和容器 UID 不一致是 90% 权限问题的根源。要么提前约定，要么动态适配：
- 开发环境：让容器用户 UID 和宿主机开发用户 UID 保持一致（比如都用 1000）
- NFS 场景：NFS 服务端导出选项加 all_squash,anonuid=1001,anongid=1001，把所有客户端请求映射到固定 UID/GID
- 生产环境：禁用 no_root_squash，改用 root_squash，并确保应用用户 UID 在 NFS 服务端有对应权限或目录 ACL 授权
额外加固建议
权限配置不是孤立动作，要和安全策略联动：
- 加 --read-only 让根文件系统只读，只对必要路径（如 /data）用 --tmpfs 或读写挂载
- 删冗余能力：--cap-drop=ALL --cap-add=NET_BIND_SERVICE（仅开放绑定端口所需）
- 避免 --privileged 和 sudo，非 root 用户也能 bind port 80（用 CAP_NET_BIND_SERVICE）
