最稳妥的基础镜像是分层构建：编译用 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。
立即学习“go语言免费学习笔记（深入）”；
- 确保集群节点启用 cgroup v2（检查
/proc/1/cgroup是否含0::/），否则 Go 1.19+ 无法准确获取内存上限 - Pod spec 中必须同时设置
resources.limits.memory和resources.requests.memory；仅设 limit 不足以触发 runtime 自适应 - 若仍观察到 OOMKilled，可在容器启动命令前加环境变量：
GOMEMLIMIT=80%（Go 1.22+ 支持百分比语法），强制 runtime 把堆上限压到 limit 的 80% - 避免在代码里硬编码
debug.SetGCPercent()—— 它会覆盖 runtime 的自动调节逻辑
为什么 livenessProbe 用 HTTP GET 很容易误杀 Go 服务
Go 默认 HTTP server 在启动瞬间就监听端口，但业务初始化（DB 连接池填充、配置加载、gRPC server 启动）可能耗时数秒。此时 probe 成功，K8s 认为服务就绪，实际请求进来却 503。
- 不要只依赖端口探测（
tcpSocket）或简单 HTTP 状态码；应在 handler 中加入就绪检查逻辑，例如返回{ "ready": true, "db": "ok", "cache": "connected" } - 使用
startupProbe替代或补充livenessProbe：设置failureThreshold: 30和periodSeconds: 10，给长初始化留出 5 分钟缓冲 - Go 程序内部可用
http.Server.RegisterOnShutdown()或信号监听做优雅退出，但 K8s 的terminationGracePeriodSeconds必须 ≥ 应用实际关闭耗时，否则 SIGKILL 强杀导致连接中断
