必须在最终运行阶段用USER指令显式设置非root用户，推荐固定使用USER 65535:65535；构建阶段（如golang镜像）绝不能提前切用户，否则因权限不足导致go mod download、go build等操作失败，出现permission denied或cannot find module错误。
必须在最终运行阶段用 USER 指令显式设置非 root 用户，且推荐固定使用 USER 65535:65535；构建阶段（如 golang 镜像）绝不能提前切用户，否则会因权限不足失败。
为什么不能在构建阶段就加 USER？
Go 构建依赖 go mod download、go build 等操作，需写入 $GOPATH、缓存目录和临时文件。这些路径默认只对 root 或构建用户可写。若在 golang 阶段就执行 USER 65535，你会立刻遇到：
-
permission denied—— 写入/go/pkg/mod失败 -
cannot find module—— 模块缓存不可读 mkdir /tmp/go-build-xxx: permission denied
多阶段构建的语义就是“构建归构建，运行归运行”，USER 只应在最终镜像（FROM alpine 或 distroless）中生效，且必须放在 COPY --from=builder 之后、CMD 之前。
USER 65535:65535 比 nobody 更可靠
nobody 在 Alpine 中 UID 是 65534，但在 distroless 镜像里通常未定义该用户名，USER nobody 会直接报错 user nobody not found。而数字 UID/GID 不查 /etc/passwd，只要合法（0–65535）就能通过校验。
立即学习“go语言免费学习笔记（深入）”；
-
USER 0或USER 1：可能意外映射到系统保留用户（如daemon），有提权风险 -
USER 1001：常见但不通用，某些基础镜像没预建该 UID，且易与宿主机用户冲突 -
USER 65535:65535：无符号 16 位最大值，在绝大多数发行版中既无系统用户占用，又明确表达“非特权”意图
它在 alpine、debian-slim、gcr.io/distroless/static-debian12 全部可用，是 Go 容器事实上的安全基线。
非 root 下启动失败的三个高频原因及修复
即使 USER 设置正确，Go 应用仍常因硬编码路径或端口崩在启动时。典型错误包括：
-
bind: permission denied：监听了:80或:443—— 改为:8080或:8443，K8s Service 的targetPort可做映射 -
open /tmp/xxx: permission denied：Go 默认用os.TempDir()，但/tmp对 UID 65535 不可写 —— 启动前加ENV TMPDIR=/dev/shm或ENV HOME=/tmp（配合RUN mkdir -p /tmp && chmod 1777 /tmp） -
mkdir /var/log: permission denied：避免写死日志路径，改用log.SetOutput(os.Stdout)，让日志走 stdout 被容器运行时接管
如何验证 USER 确实生效？
distroless 镜像没有 sh，docker exec -it xxx sh 会失败；ps aux 也跑不了。真正有效的验证方式只有两种：
- 在 Go 程序启动时加一行：
log.Printf("uid=%d, gid=%d", os.Getuid(), os.Getgid())，看日志输出是否为65535 - 用
docker inspect <container_id> | jq '.[0].Config.User'</container_id>，输出应为"65535:65535"（注意不是空字符串或"root"）
别信 groups 命令或镜像层里的 /etc/passwd —— 它们和实际运行时 UID 没有必然关系。真正起作用的是 docker run 时最终镜像的 Config.User 字段，以及内核对进程 cred 的赋值。
