gomemlimit仅控制go堆内存上限，不能防止oom；应设为容器内存limit的70%～80%，单位为字节，需配合cgroup v2使用。
Go 1.19+ 用 GOMEMLIMIT 控制堆内存上限，不是“防止OOM”的银弹
它只能让 Go 运行时更早、更主动地触发 GC，把堆压到设定值以下；但进程仍可能因栈、代码段、cgo 分配、OS 缓存等耗尽物理内存而被 OOM Killer 杀掉。
-
GOMEMLIMIT只约束 Go 堆（runtime.MemStats.HeapAlloc），不包括其他内存来源 - 设得太低（比如
512MiB）会导致 GC 频繁，CPU 升高、延迟毛刺明显 - 设得太高（比如默认的无限）或没设，在容器中容易突破
memory.limit_in_bytes被 kill - 推荐值：设为容器内存 limit 的 70%～80%，例如容器 limit 是
2GiB，则GOMEMLIMIT=1610612736（即1.5GiB，单位是字节）
GOMEMLIMIT 必须设成字节数，不能写 1G 或 512MB
环境变量只接受纯数字（字节），任何单位后缀都会被忽略，导致实际生效值远超预期——比如设成 GOMEMLIMIT=1G，Go 会尝试解析为整数，结果是 1 字节，立刻 panic。
- 正确写法：
GOMEMLIMIT=1610612736（1.5 GiB）、GOMEMLIMIT=536870912（512 MiB） - 换算建议：用
python3 -c "print(1.5*1024**3)"或直接记公式GiB × 1024³ - 验证是否生效：启动后打印
debug.ReadBuildInfo()或查runtime/debug.ReadGCStats中的NextGC是否明显下降
和 GOGC 共同作用时，GOMEMLIMIT 优先级更高
当两者都设置，Go 运行时会按「先满足 GOMEMLIMIT」逻辑调整 GC 频率；GOGC 退居辅助角色，仅影响每次 GC 后的目标增长比例。
- 例如：
GOMEMLIMIT=1GiB+GOGC=100：运行时会不断收紧 GC 触发点，确保堆长期 ≤1 GiB，哪怕此时堆才 300 MiB 也会提前 GC - 若只设
GOGC=20（非常激进），但没设GOMEMLIMIT，在内存充足机器上堆仍可能涨到几 GiB 才 GC - 生产建议：保留
GOGC=100默认值，靠GOMEMLIMIT做硬边界；调低GOGC容易引发抖动，收益有限
容器环境里必须配合 cgroup v2 和 memory.max 使用
在 Kubernetes 或 systemd 服务中，仅设 GOMEMLIMIT 不足以防 OOM——如果容器 runtime 没启用 cgroup v2，或未正确传递 memory limit，Go 根本读不到边界，GOMEMLIMIT 会 fallback 到默认值（≈ math.MaxUint64）。
立即学习“go语言免费学习笔记（深入）”；
- K8s 场景：确认节点启用 cgroup v2（
cat /proc/1/cgroup看是否有0::/）、Pod 设置了resources.limits.memory - 本地测试：用
systemd-run --scope -p MemoryMax=2G ./myapp启动，再检查/sys/fs/cgroup/memory.max - 验证 Go 是否识别：启动后执行
runtime/debug.ReadBuildInfo()，或看runtime.MemStats.TotalAlloc增长是否受控
真正卡住内存的，从来不是 Go 自己，而是它运行的那层抽象。别忘了检查 cgroup、检查 /sys/fs/cgroup/memory.max、检查 /proc/<pid>/status</pid> 里的 MMU 相关字段——这些地方出问题，GOMEMLIMIT 再准也没用。
