核心三步：创建固定UID用户、COPY时用--chown设归属、USER指令置于root操作之后；顺序错误会导致启动失败或权限异常。
直接在 Dockerfile 中配置非 root 用户运行，核心就三步：创建用户、设置文件归属、最后用 USER 切换。顺序不能错，否则容器可能启动失败或运行时写入报错。
创建固定 UID/GID 的非 root 用户
避免使用随机 UID，优先指定固定值（如 1001），防止挂载卷时与宿主机权限冲突。不同基础镜像命令略有差异：
- Debian/Ubuntu 系：
RUN adduser --disabled-password --gecos '' --uid 1001 appuser - Alpine/CentOS 系：
RUN addgroup -g 1001 -f appgroup && adduser -S -u 1001 -G appgroup appuser - 若镜像已含非 root 用户（如
node:alpine自带node用户），可复用，但需确认其 UID/GID 是否匹配挂载需求
COPY 文件时同步设置属主
复制代码或依赖后，必须确保应用目录对新建用户可读写，否则启动时无法加载配置、写日志或缓存。
- 推荐方式：在
COPY指令中直接指定归属，简洁且不易遗漏COPY --chown=appuser:appgroup . /app - 配套操作：提前建好工作目录并赋权
RUN mkdir -p /app && chown appuser:appgroup /app - 不推荐仅靠后续
RUN chown -R，易因层缓存跳过，导致归属未生效
在 root 操作完成后切换 USER
USER 指令只影响其后的 RUN、CMD 和 ENTRYPOINT，不会回溯修改之前文件的所有者。必须放在所有需要 root 权限的操作之后。
- ✅ 正确示例：
RUN apt-get update && apt-get install -y curlCOPY --chown=appuser:appgroup . /appUSER appuserCMD ["./start.sh"] - ❌ 错误示例：
USER appuser放在RUN apt-get前，会导致安装失败 - 多阶段构建中，仅最终运行阶段需设
USER；构建阶段仍可用 root 安装依赖
运行时补充加固（可选但推荐）
单靠 USER 不足以覆盖全部风险，建议结合以下措施：
- 启动容器时加
--read-only，使根文件系统只读，防止恶意篡改 - 用
--cap-drop=ALL --cap-add=NET_BIND_SERVICE按需授权 Linux 能力 - 加
--security-opt no-new-privileges阻止进程提权 - Kubernetes 环境下，通过
PodSecurityContext.runAsNonRoot: true和runAsUser强制约束
