真正落地非root容器需解决UID映射、宿主权限、能力集、命名空间四层冲突：启动失败要检查路径/端口权限，挂载写入需宿主UID对齐，日志网络问题须避免能力误删，生产环境还需只读根文件系统、裁剪能力集及启用用户命名空间映射。
让容器不以 root 身份运行，不是加一行 user 就完事。真正落地时，常卡在启动失败、文件写不了、端口绑不上、日志看不到、挂载目录权限错乱——这些问题背后，是 uid 映射、宿主权限、能力集、命名空间四层逻辑在打架。下面按真实运维节奏拆解。
容器启动即退出：先看用户和路径权限
非 root 容器最常见的“秒退”，往往不是程序崩溃，而是权限拒绝导致进程根本没起来。
- 检查
CMD或ENTRYPOINT启动脚本是否依赖/tmp、/var/run等 root-only 目录；改用容器内可写的路径，比如/app/run，并确保RUN mkdir -p /app/run && chown appuser:appuser /app/run - 确认应用监听端口是否小于 1024（如 80/443）；必须用低编号端口时，不要硬改容器内绑定，而是在
docker run时映射：-p 8080:80，容器内仍用 8080 启动 - 用
docker run -it --rm <image> sh</image>进去手动执行启动命令，观察报错；常见错误如Permission denied（文件无执行权）、No such file or directory（动态链接库缺失，尤其 Alpine 镜像缺libc）
挂载目录写入失败：宿主机 UID 必须对齐
容器里用 UID 1001 的用户，宿主机对应目录却属于 UID 1000 或 root，一写就拒。这不是 Docker 问题，是 Linux 文件系统权限本质。
- 查宿主机目录归属：
ls -ld /host/data；若显示drwxr-xr-x 1 root root，普通容器用户无法写入 - 解决方案有三选一：
— 在宿主机创建同 UID 用户：sudo useradd -u 1001 appwriter，再sudo chown -R 1001:1001 /host/data
— 构建镜像时用--chown=1001:1001复制配置文件，避免运行时依赖宿主权限
— 启动容器时用--user 1001:1001强制覆盖 Dockerfile 中的 USER，同时确保挂载点已适配
网络与日志排查：别被 root 假象误导
即使容器以非 root 运行，它仍能发请求、连外部服务、写 stdout —— 但某些操作会静默失败。
- 日志看不见？先确认是否重定向到了文件而非 stdout；非 root 用户无法写
/var/log/app.log，应改用stdout输出，由 Docker 捕获：CMD ["sh", "-c", "exec ./app 2>&1"] - 容器内 ping 不通外网？检查是否误删了
NET_RAW能力（--cap-drop=NET_RAW会导致 ping 失败）；非 root 容器默认仍有NET_BIND_SERVICE，所以 bind 高端口没问题 - 连接宿主机 MySQL 或 Redis 失败？不是权限问题，而是网络不可达 —— 默认 bridge 网络下，容器通过
host.docker.internal（Docker Desktop）或宿主机真实 IP（Linux）访问，别用127.0.0.1
生产环境加固要点：不止于 USER
只设 USER 是基础分，上线前还要补上三道锁：
-
只读根文件系统：加
--read-only启动，再用--tmpfs /run --tmpfs /tmp提供临时写入点；敏感目录如/etc可用--mount type=bind,source=/safe/etc,destination=/etc,readonly -
裁剪 Linux 能力：用
--cap-drop=ALL --cap-add=NET_BIND_SERVICE --cap-add=CHOWN精确授权，禁用SETUIDSETGIDSYS_ADMIN等高危能力 -
启用用户命名空间映射：在
/etc/docker/daemon.json中配置"userns-remap": "default"，让容器内 UID 0 映射到宿主机一个非特权 UID（如 100000），彻底隔离逃逸风险
