必须用多阶段构建+scratch，因scratch为空镜像、无任何依赖，仅能运行cgo_enabled=0禁用cgo后生成的纯静态go二进制；单阶段会打包完整工具链，导致镜像臃肿、攻击面大、运行失败。
直接用 scratch 镜像跑静态编译的 Go 二进制，是目前最轻、最安全的部署方式——前提是你的代码没启用 cgo。
为什么必须用多阶段构建 + scratch？
很多人图省事，在 Dockerfile 里直接 FROM golang:alpine 然后 go run main.go，结果镜像里塞了整个 Go 工具链、编译器、调试工具，体积动辄 300MB+，还带一堆未打补丁的系统库。Kubernetes 调度时拉镜像慢、节点磁盘压力大、攻击面也宽。
真正轻量的核心逻辑是：构建和运行彻底分离。
- 构建阶段用完整 Go 环境（如
golang:1.22-alpine）下载依赖、编译 - 运行阶段只取最终二进制，放进空镜像
scratch—— 它真的什么都没有，连/bin/sh都没有 - 这样打出的镜像通常只有 5–10MB，启动快、无冗余进程、无法执行任意命令
CGO_ENABLED=0 不只是“推荐”，而是 scratch 前提
scratch 镜像不带任何 C 运行时，一旦你的 Go 代码用了 cgo（比如调 sqlite3、libcrypto、某些 DNS 解析或系统调用封装），编译出的二进制就依赖 libc 或其他动态库，直接 panic：
standard_init_linux.go:228: exec user process caused: no such file or directory
所以构建时必须显式禁用：
-
CGO_ENABLED=0：强制纯 Go 实现，放弃 cgo 特性 -
GOOS=linux：确保目标平台一致 -
-ldflags="-s -w"：剥离调试符号和 DWARF 信息，再减几 MB - 如果确实绕不开 cgo（比如必须用硬件加速加密），那就不能用
scratch，得切回alpine:latest并apk add对应依赖
Deployment 中的镜像和入口必须严格匹配
镜像建好了，但 Kubernetes 不会自动猜你二进制叫什么、放哪、怎么跑。常见错法：
- 镜像里二进制叫
app，Deployment的command写成["./main"]→ 启动失败 - 没设
securityContext.runAsNonRoot: true，而scratch默认无 root 用户 → Pod 卡在ContainerCreating -
livenessProbe路径写错（比如写了/healthz但服务只暴露/health），导致反复重启 - 忘记在
Deployment的spec.template.spec.containers里声明ports，Service 就没法正确转发流量
最简能跑通的容器配置片段：
containers:
- name: api
image: your-registry/go-api:v1.2.0
command: ["./main"]
ports:
- containerPort: 8080
securityContext:
runAsNonRoot: true
runAsUser: 65532
alpine vs scratch：选哪个不是看体积，而是看依赖
别迷信“越小越好”。scratch 是终极精简，但代价是零容错；alpine 多出 5MB，却自带 ca-certificates、getent、基础 libc，对某些场景更稳。
- 用
scratch：纯 HTTP API、无外部系统调用、不用 TLS 证书验证（或已 embed）、不解析 /etc/passwd - 用
alpine：需要 HTTPS 请求第三方服务（要 CA 证书）、用os/user.Lookup、调exec.Command("ls")、或用了必须链接 libc 的 cgo 包 - 无论选哪个，都别在运行镜像里
apk add或apt-get install—— 这会破坏不可变性，也违背多阶段本意
真正容易被忽略的点是：scratch 下连 localhost 解析都可能失败（缺 /etc/hosts），如果你的服务启动时硬编码了 http://localhost:9090/metrics，它就会卡住。这种细节不会报错，只会让 Pod 一直 Pending 在 readiness 探针失败上。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
