gomemlimit必须设为容器内存limit的80%～90%，否则go runtime沿用math.maxuint64导致oom kill；它仅调控堆gc时机，不约束mmap/cgo等非堆内存，需禁用swap并配合cgroup硬限。
Go 程序刚跑起来 RSS 就飙到 500MB+？大概率不是代码写错了，而是运行时没告诉它“你只有这么多内存可用”——GOMEMLIMIT 没设，GOGC 还在默认值上硬扛。
为什么 GOMEMLIMIT 必须设，且要略低于容器 limit
Go 1.19+ 的运行时能感知硬内存上限，但前提是显式设置 GOMEMLIMIT。Kubernetes 里只配了 resources.limits.memory: 2Gi，却不设 GOMEMLIMIT，等于让 Go “瞎猜”自己能用多少内存。
- 后果：运行时按默认逻辑估算 GC 目标堆（比如堆存活 300MB 时，按
GOGC=100算出目标 600MB），但宿主机实际只剩 400MB 可用 → 触发强制 GC，甚至 OOMKilled - 正确做法：
GOMEMLIMIT应比容器 limit 小 5–10%，例如 limit=2Gi，就设GOMEMLIMIT=1900Mi - 验证方式：启动后查
runtime/debug.ReadGCStats或go tool trace里的memstats.GCHeapGoal，确认它没超过GOMEMLIMIT
GOGC 调高还是调低？看你的内存是否真宽松
GOGC=100 是平衡点，不是最优解。调它之前先看 runtime.ReadMemStats 里的 HeapAlloc 和 HeapSys 差值：
- 差值长期 > 300MB：说明 runtime 持有大量空闲内存没还给 OS，但堆活跃内存（
HeapAlloc）本身稳定 →GOGC可适当调高（如 150），减少 GC 频次 - 差值小但
HeapAlloc持续缓慢上涨：说明对象没被释放，调GOGC无效，得查pprof找泄漏源 - 突发流量下 GC 间隔骤缩、
PauseTotalNs暴涨：可能是GOGC设太低（如 20），导致堆稍一涨就回收，STW 频繁抖动
别忽略 GODEBUG=gctrace=1 输出里的三个关键数字
开启后每轮 GC 打印类似 gc 12 @12.345s 0%: 0.020+0.12+0.012 ms clock, 0.16+0.12/0.039/0.030+0.098 ms cpu, 512->520->256 MB, 1024 MB goal，重点盯：
-
512->520->256 MB：GC 前 → 标记后 → 清理后存活大小。若最后数字（256）逐轮抬升，说明对象在 leak，不是 GC 参数问题 -
1024 MB goal：下轮 GC 目标，等于(当前存活堆) × (1 + GOGC/100)，可反推实际生效的GOGC值 - 中间段
0.12/0.039/0.030：辅助 GC 的 goroutine 时间，若它飙升，可能标记阶段被锁阻塞，和内存参数无关，得查锁竞争
sync.Pool 用了反而内存更高？检查 Reset() 和指针残留
sync.Pool 不是开关，是双刃剑。常见踩坑点：
- Get 后没调
buf.Reset()或u = &User{}：旧数据残留，后续 Write 导致底层数组扩容，内存越用越多 - Put 前传的是
buf而不是buf[:0]：下次 Get 拿到带脏数据的 slice，可能引发隐性引用泄漏 - Pool 里塞了含
map或chan字段的 struct：GC 扫不到 Pool 内部，这些指针一直挂着，拖垮整个堆 - 命中率低（
go tool pprof -alloc_objects显示sync.Pool.Get分配量没降）：等于白加 mutex 开销，不如不用
真正起效的 Pool，必须满足：对象生命周期短、创建开销大、复用前能彻底重置、不含外部指针。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
