最稳妥的基础镜像是分层构建：编译用 golang:1.22-alpine，运行用 alpine:3.19 或 distroless/static；若依赖 cgo 需 alpine 并装 musl-dev/gcc；distroless 要求静态链接，禁用 scratch。
用什么基础镜像最稳妥
直接用 golang:latest 镜像跑生产服务是常见误区。它体积大（>900MB），含编译工具链和源码，还默认以 root 运行——这三者在容器中都该避免。
推荐分两层构建：golang:1.22-alpine 用于编译，alpine:3.19 或 distroless/static 用于运行。前者保证 CGO 和交叉编译兼容性，后者最小化攻击面。
- 若项目依赖 cgo（如调用 sqlite、openssl），必须保留 alpine 基础，且需显式安装
musl-dev和gcc - 用
distroless时，二进制必须静态链接：编译加-ldflags '-extldflags "-static"'，否则容器启动报no such file or directory - 别用
scratch镜像——它连/bin/sh都没有，exec调试、lsof查端口全失效
容器内 Golang 环境变量怎么设才不踩坑
Go 程序本身不依赖 GOPATH 或 GOROOT，但构建阶段和调试阶段会用到。关键不是“设不设”，而是“什么时候设、设给谁”。
-
GOPATH在多模块项目或老式 vendor 构建中仍有作用；现代 Go Module 项目可完全忽略它 -
GOROOT一般不用手动设——Dockerfile 中用官方镜像时，它已由镜像预置；手动覆盖反而容易导致go tool compile找不到标准库 - 真正要设的是
GOCACHE和GO111MODULE：构建阶段建议设GOCACHE=/tmp/go-cache避免层缓存失效；GO111MODULE=on强制启用模块模式，防止因vendor/存在导致行为不一致
Kubernetes Pod 中如何限制 Go 程序的内存与 GC 行为
Go 的 runtime 会根据 cgroup 内存限制自动调整 GC 频率，但前提是容器启动时正确暴露限制。K8s 默认不透传 cgroup v2 信息，旧版 Go（memory.max。
