不能直接用golang:alpine作为最终运行镜像，因为它包含go sdk、git、sh等冗余工具链，体积超300mb且cve风险高；正确做法是多阶段构建，第一阶段编译，第二阶段仅复制静态二进制到distroless镜像（如gcr.io/distroless/static:nonroot），并设cgo_enabled=0、-ldflags="-s -w -buildmode=pie"、exec格式cmd及/readyz健康端点。
为什么不能直接用 golang:alpine 作为最终运行镜像
因为 golang:alpine 包含完整的 Go SDK、go 命令、git、sh 等开发工具链，镜像体积通常超 300MB，且存在大量非必要 CVE 风险。Kubernetes 中若以此镜像部署，会因内存占用高、攻击面大、健康检查响应慢被误判为异常。
常见错误现象包括：OOMKilled（cgroup memory limit 被突破）、Readiness probe failed（/readyz 返回 503，因程序启动慢或依赖未就绪）、日志中反复出现 exec: "sh": executable file not found（误用 shell 形式 CMD 导致 distroless 启动失败）。
- 必须分离构建与运行阶段：第一阶段用
golang:1.22-alpine编译，第二阶段只 COPY 二进制到空白环境 - 最终镜像不应包含任何编译器、shell、包管理器 —— 这是
distroless的设计前提 - 若需调试，应通过 sidecar 容器挂载
busybox或使用kubectl exec -it <pod> -- sh</pod>（仅限带 shell 的基础镜像，distroless 不支持）
CGO_ENABLED=0 和 -ldflags="-s -w -buildmode=pie" 必须同时启用
Go 默认开启 CGO，一旦代码中隐式调用 net 包（如 DNS 解析）、os/user 或使用 cgo 注释，就会动态链接 libc。而 distroless/static 镜像不含 libc.so，导致容器启动时报错：standard_init_linux.go:228: exec user process caused: no such file or directory。
这个错误不是路径错了，而是动态链接器找不到 /lib/ld-musl-x86_64.so.1 或 /lib64/ld-linux-x86-64.so.2。
-
CGO_ENABLED=0强制禁用 C 语言交互，所有标准库走纯 Go 实现（例如 DNS 查询用net/lookup而非系统getaddrinfo） -
-s -w去除符号表和调试信息，可减小二进制体积 30%~50% -
-buildmode=pie启用位置无关可执行文件，满足现代安全基线（如 Kubernetes PodSecurityPolicy 要求） - 务必在构建命令中显式指定
GOOS=linux，避免本地 macOS/Windows 构建时默认生成非 Linux 可执行文件
如何正确选用 distroless 镜像并设置非 root 用户
gcr.io/distroless/static-debian12 和 gcr.io/distroless/static:nonroot 是目前最稳妥的选择 —— 前者约 2MB，后者默认以 UID 65532 运行，无需额外配置用户权限。不要用 scratch，除非你确认程序完全不依赖任何系统调用（比如不写日志、不读 /proc、不调用 getpid）。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
容易踩的坑是：在 distroless 镜像中仍沿用 CMD ["sh", "-c", "./main"]，结果容器立即退出，日志为空；或忘记加 USER 指令，导致 Kubernetes 因 runAsNonRoot: true 策略拒绝调度。
- 始终使用 exec 格式 CMD：
CMD ["/main"]，而非 shell 格式 - 优先选
gcr.io/distroless/static:nonroot，它已内置USER 65532:65532 - 若用
gcr.io/distroless/static-debian12，需手动加USER nonroot:nonroot（前提是基础镜像里定义了该用户） - 验证方式：运行容器后执行
docker inspect <image> | jq '.[0].Config.User'</image>，确认输出非空且不为root
健康检查端点与端口就绪检测必须由程序自身控制
Kubernetes 的 livenessProbe 和 readinessProbe 若只 ping 端口（tcpSocket），无法反映真实依赖状态。比如数据库连接失败、Redis 超时、证书未加载完成，程序可能已监听 :8080，但实际无法提供服务。
更危险的是：若程序在 http.ListenAndServe 后才初始化依赖，而 readiness 探针在 Listen 返回后立刻开始请求，就会造成「端口通但服务不可用」的假象，流量被错误导入。
- 必须在
net.Listen获取 listener 后、http.Serve启动前，完成所有关键依赖检查（DB 连接池、配置加载、证书校验等） -
/readyz应返回 200 仅当所有依赖就绪；/healthz可更宽松，只检查进程存活和监听状态 - Service 的
targetPort必须与程序实际Listen的端口一致（如http.Listen(":8080")→targetPort: 8080），否则流量根本进不到容器 - 启动时加
GOMEMLIMIT=80%（例如 cgroup 内存 limit 为 512Mi，则设GOMEMLIMIT=410Mi），防止 Go runtime 触发 GC 前疯狂申请内存导致 OOMKilled
实际最易被忽略的一点：很多团队把 distroless 当成“更小的 alpine”，继续在代码里调用 exec.Command("sh", "-c", "...") 或读取 /etc/passwd，结果上线后静默失败 —— distroless 不是精简版 Linux，它是无 OS 的运行时沙盒，一切行为必须严格限定在 Go 标准库纯实现范围内。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
