应设 memory.limits 略高于压测 RSS 峰值（留20%～30%缓冲），memory.requests ≥ 稳态 RSS，Go 1.19+ 需同步设 GOMEMLIMIT 为 limits 的 80%～90%，并用 containerd/cgroups 库读取真实内存上限。
怎么设 requests 和 limits 才不被 OOMKilled
Go 应用在 Kubernetes 中被 OOMKilled，90% 是因为 memory.limits 设得不合理，而不是代码有内存泄漏。Go 运行时会缓存堆内存（mcache、mspan、GC 未释放的 span），导致 runtime.ReadMemStats().Alloc 远低于实际 RSS —— 但 cgroup 看的是 RSS，超了就杀。
-
memory.limits必须略高于压测下观察到的容器 RSS 峰值（不是 Alloc），建议留出 20%～30% 缓冲；例如压测看到 RSS 顶到 380Mi，就设limits.memory: "512Mi" -
memory.requests要 ≥ 应用稳态 RSS（非 Alloc），否则调度器可能把它塞进资源吃紧的节点，引发争抢 - 绝对不要设
limits.memory为"0"或空字符串，Kubernetes 会当无限处理，节点 OOM 风险陡增 - 若用 Go 1.19+，务必同步设环境变量
GOMEMLIMIT为limits.memory的 80%～90%，比如512Mi → GOMEMLIMIT=4294967296（即 4Gi 字节），让 runtime 主动配合 cgroup 限界
为什么只调 GOGC 和 GOMAXPROCS 不管用
GOGC 控制 GC 触发频率，GOMAXPROCS 控制 P 数量，二者都不限制内存占用上限或 CPU 时间片——它们只是运行时策略，不是资源配额。真正起作用的只有 Kubernetes 的 resources.limits，靠底层 cgroups 强制 enforce。
- 设了
GOGC=20但没设memory.limits？Go 可能缓存几 GB 内存，最后被 kernel 用 signal 9 杀掉，dmesg -T | grep -i "killed process"才能看到真相 -
GOMAXPROCS默认是runtime.NumCPU()，而该函数返回的是容器cpuset.cpus允许的逻辑核数（如--cpus=1.5时返回 1），不是宿主机总核数；但它不阻止 CPU throttling，超cpu.limits后照样被限流，延迟飙升 - 想让 Go “感知”配额，必须读 cgroup：用
github.com/containerd/cgroups加载cgroups.V2或V1，再取stats.Memory.Max或stats.Memory.Usage.Limit，不能硬编码路径
怎么读 cgroup 获取真实内存上限（别再硬解析文件）
手动读 /sys/fs/cgroup/memory.max 或 /sys/fs/cgroup/memory/memory.limit_in_bytes 容易踩坑：v2 返回 "max" 字符串、v1 返回 -1 表示无限制、非 root 用户可能权限拒绝——直接 strconv.ParseUint 会 panic 或误判。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 推荐用
containerd/cgroups库：cgroups.Load(cgroups.V2, cgroups.Pid(1))自动适配版本，失败时 fallback 到默认值（如512 * 1024 * 1024） - 读到的
stats.Memory.Max是字节单位，若等于math.MaxUint64，说明没设 limit，此时不应触发降级逻辑 - 主动监控使用率：读
stats.Memory.Usage.Current/stats.Memory.Max，> 85% 时可关闭健康检查采样、降低日志等级、拒绝新 HTTP 连接 - 别依赖
runtime.ReadMemStats()做限流判断——它反映的是 Go 堆分配，不是容器 RSS，两者差常达 2～3 倍
常见 YAML 配置错误与修复建议
Kubernetes Pod 的 resources 写错一个字段，轻则调度失败，重则上线即崩。最常出问题的是单位混淆、request/limit 比例失衡、以及忽略 cpu 的小数表达。
立即学习“go语言免费学习笔记（深入）”；
-
cpu: "1"≠cpu: "1000m"：前者是 1 核，后者是 1000 毫核，等价；但"100m"是 0.1 核，不是 100 核 - request 和 limit 的比值很重要：
requests.cpu太低（如"10m"）会导致调度器把它打到任意节点，但limits.cpu: "500m"又太高，容易触发 throttling；建议 request ≈ 稳态负载，limit = request × 2～3 - 内存单位必须用
Mi（mebibytes），不是MB；写成"512MB"会被 K8s 当作 512 字节处理，Pod 直接 CrashLoopBackOff - 没配
readinessProbe和livenessProbe？流量可能打到还没初始化完的实例，尤其 Go 应用启动快但依赖服务连接慢，probe 超时设置太短也会误杀
Go 应用跑在容器里，真正的资源边界从来不在代码里，而在 cgroup 文件和 YAML 的 resources 字段中；所有运行时调优都得先确保这个边界清晰、合理、可测量。
