必须禁用CGO并设置GOOS=linux，否则容器因缺失glibc报“no such file or directory”；多阶段构建推荐scratch镜像，需显式处理DNS和路径；GOMEMLIMIT须设为limits的80%~90%，探针路径须独立轻量且initialDelaySeconds≥5秒。
Go应用容器化时必须禁用CGO并设置GOOS=linux
直接在Kubernetes中部署未适配的Go二进制会导致启动失败或OOMKilled——因为默认构建会链接glibc，而alpine或scratch镜像没有它。CGO_ENABLED=0和GOOS=linux是硬性要求，否则容器内找不到动态链接库，报错类似standard_init_linux.go:228: exec user process caused: no such file or directory。
多阶段构建中，运行阶段建议用scratch而非alpine：更小、更安全，但需确保不依赖任何系统工具（如curl、sh）。若应用需DNS解析，scratch镜像要显式复制/etc/resolv.conf或设ENV GODEBUG=netdns=go避免cgo DNS查找失败。
-
go build -ldflags="-s -w"可剥离调试符号，减小二进制体积约20%–30% - 不要在Dockerfile里写
RUN go build后又COPY . .——源码复制应在构建前完成，否则缓存失效 - 镜像tag必须用语义化版本（如
v1.2.0），禁用latest，否则Kubernetes无法感知更新
Deployment中memory限制必须同时设requests和limits
Kubernetes调度器只看requests决定Pod能落在哪个节点上；而limits才是OOMKilled的触发阈值。只设limits不设requests，等于告诉调度器“这Pod随便塞哪都行”，结果可能挤在内存紧张的节点上，一压就崩。
Go程序的内存行为特殊：runtime会向OS申请大块内存（mheap），但不会轻易归还。即使应用实际只用100Mi，top或kubectl top pod可能显示RSS达300Mi+。所以limits不能只按“当前用量”设，得留余量。
- 初始配置建议：
requests: 128Mi，limits: 256Mi（比例2:1） - 上线后观察
kubectl describe pod <name>里的QoS Class：只有Guaranteed（requests==limits）才保证不被驱逐；Burstable（仅requests）在节点压力下可能被杀 - 若频繁出现
OOMKilled，先检查go tool pprof堆快照，再调高limits——别盲目调低GOGC
Go运行时需适配容器内存限制，否则GC不生效
Go 1.19+支持GOMEMLIMIT环境变量，它会强制runtime将堆内存控制在指定值内（含预留空间）。若不设，runtime默认按机器总内存计算GC触发点，在容器里会严重误判——比如节点有16Gi内存，Pod只分到256Mi，但GC仍等堆用到几Gi才回收，最终OOMKilled。
正确做法是在Deployment的env里加：GOMEMLIMIT: "200Mi"（比limits小10%~20%，留出runtime元数据开销）。这个值必须是字节或带单位的字符串（如209715200或200Mi），不能写200M（会被当兆字节，差1000倍）。
-
GOMEMLIMIT优先级高于GOGC；设了前者，后者只影响GC频率微调 - 低于Go 1.19的版本，只能靠
GOGC=10（激进回收）+GOMAXPROCS限P数来缓解，但治标不治本 - 验证是否生效：进入Pod执行
go version确认≥1.19，再cat /sys/fs/cgroup/memory.max（cgroup v1）或cat /sys/fs/cgroup/memory.max（v2）看是否匹配
健康探针路径必须独立于业务逻辑且轻量
livenessProbe和readinessProbe如果复用/或/api/v1/status这类端点，一旦DB连不上或下游超时，探针失败→重启→死循环。Go服务应提供专用HTTP handler，只检查自身状态，不碰外部依赖。
典型错误是把readinessProbe写成“能连DB就算就绪”，结果数据库慢导致Pod卡在ContainerCreating状态，Service流量永远进不去。
- 就绪探针建议：返回
200 OK+ 简单文本，例如"ready: true"，且不记录日志（避免干扰stdout日志采集） - 存活探针建议：检查HTTP服务器是否还在accept连接，可用
http.Get("http://localhost:8080/healthz")自检，避免引入额外依赖 -
initialDelaySeconds必须大于Go应用冷启动时间（main函数执行+HTTP server listen+监听端口完成），实测至少5秒起，复杂初始化（如加载大配置、预热cache）需设15–30秒
GOMEMLIMIT设错、CGO_ENABLED漏关、探针路径耦合业务，这三个点踩中任意一个，都会让服务上线后行为不可预测。 
