GOMEMLIMIT才是容器防OOM第一道防线，因它管控进程总虚拟内存，而GOGC仅控制堆增长比例；长连接网关中goroutine栈、socket buffer等非堆内存上涨快，OOM常发生在堆仅用一半时。
直接设 GOMEMLIMIT，别只调 GOGC；它才是容器环境下防 OOM 的第一道防线，GOGC 只管堆增长比例，而 OOM 杀死进程时往往堆才用了一半。
为什么 GOMEMLIMIT 比 GOGC 更关键
长连接网关服务内存占用不是线性的：连接数上升后，goroutine 栈、mcache、TLS 缓冲区、net.Conn 底层 socket buffer 都会涨，但这些都不算在“堆”里。默认 GOGC=100 会等堆翻倍才触发 GC，可此时总虚拟内存早已逼近容器 limit（比如 512MiB），OS 直接 OOMKilled——你连 GC 日志都看不到。
-
GOMEMLIMIT作用于整个进程虚拟内存（Go 1.19+），单位支持MB/GB（不区分大小写），不能带引号 - 压测实测常驻内存 850MB → 设
GOMEMLIMIT=1GB；容器限制 512MiB → 设GOMEMLIMIT=400MiB - 和
GOGC共存时，GOMEMLIMIT优先级更高：哪怕堆只涨了 10%，只要总内存快到上限，GC 就强制启动 - 错误写法：
GOMEMLIMIT="1GB"（引号导致忽略）、GOMEMLIMIT=256MB（太低引发 GC 频繁、CPU 反升）
怎么配 GOGC 才不拖慢长连接响应
GOGC 不是越小越好，它控制的是堆增长比例触发 GC 的节奏。网关类服务高频分配小对象（如包头解析、session 结构体），GOGC 设太低会导致 GC 太勤，STW 时间叠加，P99 延迟毛刺明显。
- 通用值
GOGC=50：适合内存敏感、连接数中等（ - 高吞吐低延迟场景（如游戏网关）可试
GOGC=20，但必须配合GOMEMLIMIT使用，否则内存抖动更大 - 禁止写成
export GOGC="50"（引号失效），Docker 启动时用-e GOGC=20 - 运行时可动态调：
runtime.SetGCPercent(20)，返回旧值便于灰度回滚
必须配合可观测性验证，否则全是猜
参数改完不看效果，等于没调。长连接服务的 GC 行为必须结合真实流量观察，不能只靠本地单连接压测。
- 启动前加
GODEBUG=gctrace=1，关注日志里gc N @X.XXXs ... X->X->Y MB, Z MB goal这行：如果goal频繁跳变或inuse_space持续贴近GOMEMLIMIT，说明设得太紧 - 访问
/debug/pprof/heap看inuse_space和每秒allocs：若 allocs > 10MB/s，说明热路径有逃逸或重复 new，该优化代码而非调参 - Kubernetes 中建议用 Downward API 注入
limits.memory，再脚本自动算出GOMEMLIMIT（如取 80%），避免硬编码
最易被忽略的一点：GC 参数只是兜底，不是替代资源管理。连接泄漏、未复用 sync.Pool、协议解包时反复 make([]byte, n)，这些都会让任何 GC 配置失效。先 fix goroutine 泄漏，再调参。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
