go二进制默认静态链接、无libc和go运行时依赖，可直接运行于scratch镜像；多阶段构建应分离golang构建镜像与scratch/alpine/debian运行镜像，禁用cgo时优先选scratch，启用cgo时选debian:slim并安装ca-certificates，同时创建非root用户降权运行。
用多阶段构建避免镜像体积爆炸
Go 编译出的二进制是静态链接的，不依赖 libc 或 Go runtime，所以运行时根本不需要 golang 镜像——直接扔进空镜像也能跑。但很多人误用 FROM golang:1.24-alpine 作为最终镜像，结果打出 300MB+ 的镜像，还暴露了编译工具链，纯属安全与性能双输。
正确做法是严格分离「构建阶段」和「运行阶段」：
- 构建阶段用
golang:1.24-alpine或golang:1.24-bullseye（后者更适合 CGO 场景） - 运行阶段优先选
scratch（零依赖，几 MB），若需 ca-certificates 或 tzdata，再退到alpine:latest或debian:slim - 务必用
COPY --from=builder只拷二进制，不带源码、go.mod、测试文件
为什么别默认用 alpine 作运行基础镜像
alpine 小是小，但它用的是 musl libc，而部分 Go 项目开启 CGO_ENABLED=1（比如用了 net 包的 DNS 解析、或依赖 cgo 的库如 sqlite3）时，会动态链接系统 libc。musl 和 glibc 行为不完全一致，容易在 DNS 超时、SSL 验证失败等场景静默出错。
稳妥方案：
- 先确认是否真需要 cgo：本地执行
go build -ldflags="-v" .，看输出里有没有libgcc或libc相关链接痕迹 - 若无需 cgo，编译时加
CGO_ENABLED=0，就能放心用scratch - 若必须 cgo，运行镜像改用
debian:slim，并显式RUN apt-get update && apt-get install -y ca-certificates && rm -rf /var/lib/apt/lists/*
如何让容器以非 root 用户运行
默认 Docker 容器以 root 启动，一旦服务被攻破，攻击者就拿到 root 权限。Go 二进制本身无权限要求，完全可以降权运行。
关键操作：
- 在运行阶段镜像中，用
RUN adduser -u 1001 -D appuser创建无家目录、UID 固定的用户 - 用
USER appuser切换身份（注意：必须在COPY二进制之后，否则可能因权限不足无法复制） - 确保二进制文件对
appuser可执行：RUN chmod +x /main && chown appuser:appuser /main - 验证：容器启动后执行
ps aux | grep main，看 USER 列是不是appuser
忽略 go mod vendor 导致镜像构建失败
有些团队开了 GO111MODULE=on 但没配 GOPROXY，或私有模块未接入代理，在构建阶段 go mod download 直接超时失败；还有人把 vendor/ 提交进 Git，却在 Dockerfile 里漏掉 COPY vendor vendor，导致构建时找不到本地依赖。
推荐写法：
- 构建阶段开头固定设环境：
ENV GO111MODULE=on GOPROXY=https://goproxy.cn,direct - 如果用了
vendor，COPY go.mod go.sum vendor/ .（注意末尾斜杠，表示复制目录内容） - 避免
COPY . .，它会把.git、README.md全塞进镜像层，增大体积且泄露信息
最易被忽略的一点：当项目含多个 main 包（如 cmd/api、cmd/rpc），go build -o main . 会失败——必须明确指定路径，例如 go build -o api ./cmd/api，否则构建卡在“no main package”错误里。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
