oomkilled 的确认需先查 kubectl describe pod 的 events 中 warning oomkilled 及退出码 137；再核对 status 列、--previous 实例和 dmesg 记录；同时验证容器 rss 是否真实超 cgroup limit，而非仅依赖 go memstats 或 top res。
查 OOMKilled 状态和容器退出码
Pod 被杀后第一反应不是翻日志，而是确认是不是真被 OOMKilled —— 很多“内存爆炸”其实是 panic 或 init 容器失败伪装的。用 kubectl describe pod <name></name> 看 Events 区域，重点找这行：
Warning OOMKilled 2m10s kubelet Container <container-name> exited with code 137
注意：code 137 = signal 9（SIGKILL）+ 128，是内核 OOM Killer 下手的铁证；如果是 139 就是 segfault，别带偏节奏。
-
kubectl get pod -o wide看 STATUS 列是否显示OOMKilled（不是CrashLoopBackOff） - 如果 Pod 已重建，用
kubectl get pod --previous拉上一个实例再查 - Node 上的
dmesg -T | grep -i "killed process"能看到内核级记录，含被杀进程 RSS 和 cgroup memory limit
看 Go runtime 的内存指标是否“诚实”
Go 的 runtime.ReadMemStats 返回的是 Go 自己记的堆/栈/系统分配，但不包含 CGO 分配、mmap 内存、未归还给操作系统的页，更不反映 container cgroup 的实际 RSS。所以 MemStats.Alloc 显示才 200MB，RSS 却飙到 2GB 是完全可能的。
- 用
curl http://localhost:6060/debug/pprof/heap?debug=1看实时 heap profile，重点关注inuse_space和alloc_space差值大不大（说明有大量短命对象） - 加
GODEBUG=madvdontneed=1环境变量能让 Go 更积极把空闲内存交还 OS（默认在 Linux 上是madvise(MADV_FREE)，不保证立即回收） - 避免在 hot path 大量用
unsafe.Slice或C.malloc，这些完全绕过 runtime 统计
验证容器 RSS 是否真超限
K8s 的 memory.limit 是 cgroup v1 的 memory.limit_in_bytes 或 v2 的 memory.max，而容器里看到的 cat /sys/fs/cgroup/memory/memory.usage_in_bytes 才是真实 RSS（含 page cache、匿名页等）。别只信 top 或 ps aux 的 RES 列——它在容器里常不准。
立即学习“go语言免费学习笔记（深入）”；
- 进容器执行：
cat /sys/fs/cgroup/memory/memory.usage_in_bytes和cat /sys/fs/cgroup/memory/memory.limit_in_bytes，做除法看占用率 - 如果 usage 接近 limit 且持续数秒，cgroup 就会触发 OOM Killer；哪怕 Go runtime 显示内存很空，也拦不住
- 用
node_exporter抓container_memory_usage_bytes{container="<name>"}</name>比应用自报指标更可信
限制 Go 的 GC 频率别靠调 GOGC
GOGC=100 是默认值，意思是“当新分配量达到上次 GC 后存活堆的 100% 时触发 GC”。但它对 RSS 几乎没约束力——GC 只管回收 Go 堆，不管 mmap、CGO、OS page cache。盲目调低（比如设成 20）只会让 GC 更频繁、CPU 更高，RSS 却纹丝不动。
- 真正压 RSS 的手段是控制最大堆目标：
debug.SetGCPercent(-1)关 GC + 手动runtime.GC()，或用debug.SetMemoryLimit（Go 1.19+）设硬上限 -
debug.SetMemoryLimit是基于 RSS 的软上限，runtime 会主动触发 GC 并延迟分配来靠近它，比GOGC更贴近容器限制场景 - 别在 prod 里用
runtime/debug.FreeOSMemory()，它只是把 idle heap 归还 OS，现代 Go 版本已很少需要
最常被忽略的一点：Go 应用在 K8s 里跑，它的内存压力源往往不在 Go 代码本身，而在 HTTP body 缓冲、gRPC streaming 的接收窗口、logrus 的异步 buffer、甚至 Prometheus client 的 metric 持久化缓存——这些地方的容量控制，比调 GOGC 实在得多。
