核心是显式创建固定uid（如1001）的非root用户，统一文件属主（copy --chown或run chown），在所有root操作后执行user指令，并验证进程uid、路径归属及写入权限。
在 Dockerfile 中定义容器默认用户权限与 UID，核心是显式创建一个固定 UID 的非 root 用户，并确保所有文件归属、运行上下文和权限设置都围绕该用户展开。不写 USER 指令，容器就默认以 root（UID 0）运行；写了但没提前创建用户，构建会失败；创建了用户却不统一文件属主，运行时仍可能因权限拒绝而崩溃。
明确创建 UID 固定的用户
避免使用动态或系统默认 UID（如 1000 可能与宿主机冲突），推荐用 1001、1002 等明确值，并兼顾不同基础镜像的语法差异：
- Alpine/CentOS：RUN addgroup -g 1001 -f appgroup && adduser -S -u 1001 -G appgroup appuser
- Debian/Ubuntu：RUN groupadd -g 1001 appgroup && useradd -r -u 1001 -g appgroup -m -s /bin/sh appuser
- 支持参数化（便于 CI/CD 调整）：ARG UID=1001 && ARG GID=1001 && RUN groupadd -g $GID appgroup && useradd -r -u $UID -g $GID -m appuser
COPY 文件时同步设置属主
复制应用代码或配置时，直接指定目标用户和组，比后续 chown 更简洁可靠：
- COPY --chown=appuser:appgroup ./src /app
- COPY --chown=appuser:appgroup config.yaml /etc/myapp/config.yaml
- 若未用 --chown，必须补 RUN chown -R appuser:appgroup /app，否则文件仍属 root，非 root 用户无法读写
在合适位置插入 USER 指令
USER 必须放在所有需要 root 权限的操作之后（如 apt install、mkdir、chown），且要早于 CMD/ENTRYPOINT：
- 错误顺序：USER appuser → RUN apt update（会报 permission denied）
- 正确顺序：RUN apt update && apt install ... → COPY --chown=... → USER appuser → CMD ["./start.sh"]
- 可只写 UID：USER 1001，更稳定（避免用户名解析失败）
验证是否生效
镜像构建完成后，务必验证三件事：
- 启动临时容器：docker run --rm -it your-image sh
- 检查进程 UID：ps -eo pid,user,comm | grep start
- 确认关键路径归属：ls -ld /app /etc/myapp 和 ls -l /app/start.sh
- 模拟写入测试：su -c "echo test > /app/test" appuser，看是否成功
