OOMKilled即内存超限被系统强杀，验证需查kubectl get pods的STATUS列或退出码137；Go应用易触发因默认不感知容器内存限制，须配GOMEMLIMIT、禁CGO、暴露pprof定位内存热点。
怎么一眼确认是OOMKilled而不是其他崩溃
直接看 kubectl get pods 输出里的 STATUS 列：出现 OOMKilled 就是内存被系统强杀，不是应用自己 panic 或启动失败。注意它常和 CrashLoopBackOff 混在一起——后者只是表象，OOMKilled 才是根因。
更准的验证方式是查退出码：kubectl get pod <pod-name> -o jsonpath='{.status.containerStatuses[0].lastState.terminated.exitCode}'</pod-name>
返回 137（即 128 + 9），说明收到了 SIGKILL，基本锁定 OOM。
常见干扰项：
- ExitCode: 1 或 2：通常是应用启动失败、配置错误或 panic
- ContainerCreating 或 Pending：和 OOM 无关，是调度或镜像拉取问题
为什么Go应用在K8s里特别容易OOMKilled
Go 运行时默认不感知容器内存限制，runtime.MemStats 看到的是节点总内存，不是容器 limits.memory。当 Go 的堆增长 + 未释放的 goroutine 内存 + CGO 分配的 native memory 超过 limits，内核就直接 kill 进程。
几个典型诱因：
- 没设 GOMEMLIMIT（Go 1.19+ 推荐），导致 runtime 无上限增长
- 使用了 CGO_ENABLED=1 且调用了 C 库（如 SQLite、libpq），这部分内存不受 GC 管理
- 并发处理大量请求时，临时对象堆积（如未复用 bytes.Buffer、sync.Pool 未合理使用）
- 日志写入没节制，尤其用 log.Printf 拼接大字符串，触发大量临时分配
对比 Java，Go 没有 -Xmx 那种显式堆上限，但 GOMEMLIMIT 是等效机制，必须配。
怎么快速定位Go应用内存暴增点
别等 Pod 死了再查。提前在代码里暴露 /debug/pprof/heap，然后用 kubectl port-forward 抓快照：
kubectl port-forward <pod-name> 6060:6060 go tool pprof http://localhost:6060/debug/pprof/heap
进 pprof 后输入 top，重点关注：
- runtime.mallocgc 占比是否异常高
- net/http.(*conn).serve 下面是否有大量未关闭的连接或 body 缓冲
- 自定义结构体（尤其是含 []byte、map、chan 的）是否在 handler 中持续 new
如果无法暴露端口，也可以在容器退出前 dump：kubectl exec <pod-name> -- sh -c 'kill -ABRT 1 && sleep 1'</pod-name>（触发 core dump，需容器支持）
但更稳妥的是加日志：在关键 handler 入口/出口打 runtime.ReadMemStats，输出 Alloc 和 HeapInuse。
部署时必须加的Go运行时参数和资源配置
光写 resources.limits.memory: "512Mi" 不够，Go 必须同步感知这个限制：
- 容器启动命令里加环境变量：
GOMEMLIMIT="400Mi"（建议设为 limit 的 70%~80%，留余量给 runtime 开销） - Dockerfile 中避免
CGO_ENABLED=1，除非真需要；若必须用，加export GODEBUG=madvdontneed=1减少 native memory 滞留 - Pod spec 中明确设
requests.memory和limits.memory，且 requests ≤ limits，否则 QoS 类为Burstable，OOM 优先级更高 - Java 用
-XX:MaxRAMPercentage，Go 就用GOMEMLIMIT，二者逻辑一致——都是让 runtime 主动限流，而非等内核动手
最容易被跳过的点：GOMEMLIMIT 值单位必须带 Mi 或 Gi，写成 400（无单位）会被忽略；另外它只在 Go 1.19+ 生效，老版本得靠 GOGC + 手动监控兜底。
