go服务oomkilled主因是runtime未感知cgroup内存限制，1.19前按宿主机内存估算gc触发点；应优先读取cgroup内存限制、设置gomemlimit（留10%缓冲）或debug.setmemorylimit，配合gogc调优与guaranteed qos保障。
Go服务被OOMKilled不是内存用多了，而是runtime没“看见”限制
Go 1.19之前默认按宿主机总内存估算GC触发点，哪怕Kubernetes设置了resources.limits.memory: 512Mi，runtime仍可能在400Mi就尝试分配大块堆内存，结果被内核OOM Killer直接干掉。这不是代码泄漏，是运行时和cgroup脱节。
- 优先读取
/sys/fs/cgroup/memory.max（cgroup v2）或/sys/fs/cgroup/memory.limit_in_bytes（v1），过滤掉max等非数字后缀再转为字节数 - Go 1.19+ 直接设环境变量
GOMEMLIMIT，但值不能硬编码：比如limit是512Mi，应算GOMEMLIMIT=$((512 * 1024 * 1024 * 90 / 100))（留10%缓冲） - 旧版Go用
debug.SetMemoryLimit()，必须在main()最开头调用，且早于任何goroutine启动 - 别信
docker stats里显示的“used”——那是RSS，OOM Killer看的是memory.max+ page cache + anon memory总和
多阶段构建不干净，二进制偷偷带libc依赖
镜像里跑ldd /main输出一堆so路径？说明CGO_ENABLED=0没生效，或者build阶段用了golang:alpine但run阶段用alpine，musl和glibc混用导致动态链接失败——容器启动时直接报standard_init_linux.go:228: exec user process caused: no such file or directory，后续根本没机会跑起来就被K8s判定为CrashLoopBackOff。
- build命令必须同时指定
CGO_ENABLED=0 GOOS=linux GOARCH=amd64（或目标架构） - run阶段别用alpine，改用
gcr.io/distroless/static-debian12，彻底规避libc问题 - 验证是否真静态：
docker run --rm -it <image> /bin/sh -c "ldd /main"</image>，输出应为not a dynamic executable - Dockerfile里
COPY . .前别go mod download，缓存可能引入隐式依赖
资源配额和GOMAXPROCS/GOGC不联动，CPU和内存一起卡死
--cpus=1下延迟毛刺严重，不是CPU不够，是Go调度器按宿主机逻辑核数创建P，结果大量goroutine在quota耗尽后排队；同样，内存limit设了但GOGC没调，GC仍按宿主机内存估算，频繁STW拖慢响应，还容易触发liveness probe误杀。
在 Golang 中使用 samber/hot 进行内存缓存，支持 LRU、LFU、TinyLFU、W‑TinyLFU、S3FIFO、ARC、TwoQueue、SIEVE、FIFO 等淘汰算法，提供 TTL、缓存加载器及分片功能。
- 设
GOMAXPROCS=0（Go 1.15+支持），它会自动读取/sys/fs/cgroup/cpu.max推算可用核数 - 根据
GOMEMLIMIT反推GOGC：比如limit 512Mi、GOMEMLIMIT设460Mi，可设GOGC=30（降低GC频率，避免频繁STW） - Kubernetes中必须用
GuaranteedQoS：requests和limits值完全一致，否则cgroup配额不生效 - 用
GODEBUG=schedtrace=1000观察日志：idleprocs长期>0、runqueue持续堆积，就是调度饥饿信号
readinessProbe配置和Go启动时机错位，流量打进来时server还没ready
HTTP服务用http.ListenAndServe(":8080")是阻塞调用，但K8s的probe在容器启动后立刻发请求。此时listener可能刚bind，TLS握手、中间件、路由注册都还没完成，probe返回200，流量涌入，结果panic或超时——这不是probe写错了，是启动模型没对齐。
- 改用
net.Listen("tcp", ":8080")先获取listener，再传给&http.Server{Addr: "", Handler: h}.Serve(lis) - readinessProbe必须配
initialDelaySeconds: 5和failureThreshold: 3，防GC STW或冷启动误判 - 就绪端点（如
/readyz）要检查真实依赖：db.PingContext()、redis.Ping()，任一失败返回503 - 别在
init()里做重操作——它阻塞包加载，错误难定位；初始化逻辑收拢到main()或独立setup()函数，加timeout和重试
真正容易被忽略的是GOMEMLIMIT和GOGC的联动关系：只设GOMEMLIMIT但GOGC太高，GC太懒，堆涨到接近limit才触发，一次回收压力巨大；GOGC太低又导致GC太勤，STW拖慢请求。这个平衡点必须结合实际压测数据调，没法靠文档抄出来。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
