核心是显式创建固定UID的非root用户并闭环文件归属、切换时机和运行验证。需用adduser等命令指定UID（如1001），提前chown应用目录，USER指令置于所有root操作之后，并通过ps检查、脚本防护及docker-compose user配置验证生效。
核心是显式创建固定 UID 的非 root 用户，并确保文件归属、切换时机和运行验证三者闭环。不是加一行 USER 就完事，而是从构建开始切断对 root 的依赖。
创建确定 UID 的用户，别用随机分配
随机生成用户（如 adduser appuser 不带 --uid）会导致挂载卷时权限错乱——宿主机上属主是 1001 的目录，在容器里用 UID 999 的用户根本写不了。必须显式指定 UID，且建议与开发/生产环境常用用户保持一致（如 1001）：
- Debian/Ubuntu：
RUN adduser --disabled-password --gecos '' --uid 1001 appuser - Alpine：
RUN addgroup -g 1001 -f appgroup && adduser -S appuser -u 1001 -G appgroup - CentOS/RHEL：
RUN useradd -m -u 1001 -g 1001 appuser
应用目录属主必须提前改，否则启动就失败
代码和依赖安装完后，默认整个 /app 目录属 root。切换 USER 后，新用户无权读配置、写日志、建缓存，CMD 直接报 Permission denied。必须在 USER 指令前完成归属变更：
-
COPY . /app后立即执行：RUN chown -R appuser:appgroup /app - 若用多阶段构建，只在最终 stage 做这一步；构建阶段仍可用 root 安装依赖
-
WORKDIR /app本身也要确保属主正确，可加：RUN mkdir -p /app && chown appuser:appgroup /app
USER 指令位置不能错，否则后续 RUN 会中断
USER 必须放在所有需要 root 权限的操作之后。比如 apt、pip、npm install 都得在切换前完成。
- 错误写法：
USER appuser→RUN pip install -r requirements.txt（失败：权限不足） - 正确顺序：
RUN pip install→COPY . /app→RUN chown→USER appuser - 如果基础镜像已带非 root 用户（如
node:20里的node用户），优先复用，查清其 UID 再USER node，避免重复创建
运行时验证是否生效，别只看 Dockerfile
构建完别假设它起效。启动容器后快速检查进程 UID：
-
docker run --rm your-image ps -eo uid,user,args | head -n 2—— 第二行 UID 应为 1001，不是 0 - 在
CMD或ENTRYPOINT脚本开头加防护：if [ "$(id -u)" = "0" ]; then echo "ERROR: root not allowed"; exit 1; fi - Docker Compose 中可兜底：
services: app: user: "1001:1001"，覆盖镜像内设置
