必须显式设置CGO_ENABLED=0和GOOS=linux以生成静态二进制，否则Alpine/scratch镜像中因缺失glibc或目标系统不匹配导致容器启动失败；探针路径、端口须与Go服务实际监听一致，且initialDelaySeconds建议≥10秒；镜像tag禁用latest，优先用语义化版本。
直接用多阶段构建的 Dockerfile 打包 Go 应用，再部署到 Kubernetes，是最轻量、最安全、也最容易出问题的环节——关键不在“能不能”，而在“哪几处不设防就会导致 Pod 启动失败或健康检查一直不通过”。
CGO_ENABLED=0 和 GOOS=linux 必须显式设置
Go 默认启用 CGO，编译出的二进制会动态链接 libc；而 Alpine 或 scratch 镜像里没有 glibc，运行时直接报 standard_init_linux.go:228: exec user process caused: no such file or directory。
-
CGO_ENABLED=0强制静态链接，消除对系统 C 库的依赖 -
GOOS=linux确保交叉编译目标是 Linux（即使你在 macOS 或 Windows 上构建） - 漏掉任一参数，镜像能 build 成功，但容器启动就 crash，
kubectl logs只显示空行或上述错误
运行阶段别用 alpine:latest，优先选 scratch 或固定版本 alpine
alpine:latest 不稳定，某天更新后可能移除 /bin/sh 或改变证书路径，导致 CMD ["./main"] 失败或 HTTPS 请求报 x509: certificate signed by unknown authority。
- 用
FROM scratch最干净：只含二进制 + 必要文件（如 certs），体积常压到 5–10MB - 若需调试或加 ca-certificates，用
FROM alpine:3.20（而非 latest），再RUN apk --no-cache add ca-certificates - 别在 scratch 镜像里 COPY
/etc/ssl/certs/ca-certificates.crt—— 它不存在，会静默失败
Deployment 中 livenessProbe/readinessProbe 的路径和端口必须匹配 Go 服务实际监听行为
很多 Go 服务只注册了 /health，但 Deployment 写成 path: /readyz，结果 readinessProbe 一直 fail，Pod 卡在 ContainerCreating 或反复重启。
- 确认 Go 服务是否真起了 HTTP server：
http.ListenAndServe(":8080", nil)是最简写法，但没注册任何 handler，默认返回 404；健康检查路径必须有显式 handler - Probe 的
port要和容器containerPort一致，且不能写成 hostPort -
initialDelaySeconds别设太小：Go 服务冷启动可能加载 config、连接 DB，5 秒不够，建议至少 10–15 秒
镜像 tag 必须用语义化版本，禁止用 latest
Kubernetes 默认不会拉取新 latest 镜像，哪怕你本地 docker push 更新了。它只认 image digest 或明确 tag。
- Deployment 中写
image: my-registry/go-app:latest→ 部署后永远是第一次 pull 的旧镜像 - 正确做法：
image: my-registry/go-app:v1.2.3，配合 CI 自动递增 - 如果非要用 latest，得加
imagePullPolicy: Always，但这是反模式：无法审计、回滚困难、CI/CD 流水线不可重现
真正容易被忽略的是：Dockerfile 里 COPY --from=builder 的路径必须和 RUN go build -o 输出路径严格一致，一个斜杠错位，最终镜像里就没有可执行文件——kubectl describe pod 显示 Back-off restarting failed container，但日志为空，排查起来最耗时间。
