确认GC压力来源需先观察gctrace中存活堆是否持续上涨，若上涨则是代码泄漏或缓存未清理；若HeapAlloc暴涨才是分配过猛，应结合逃逸分析定位。
GOGC 和 GOMEMLIMIT 必须在容器启动前就设好，运行时改无效；编译期加 -gcflags="-m -m" 才能真实看到逃逸路径，光靠经验猜对象分配位置会误判。
怎么确认 GC 压力真来自代码还是参数配置？
别一上来就调 GOGC。先用 GODEBUG=gctrace=1 启动，观察日志里 512->520->256 MB 这段：如果最后数字（存活堆）持续爬升，说明对象没释放，不是 GC 参数问题，是代码泄漏或缓存未清理；如果 HeapAlloc 在两次 GC 间暴涨（比如从 100MB → 400MB），才是分配过猛，该看逃逸分析。
- 用
go tool trace看GC pause和heap growth曲线是否同步——不同步大概率是分配侧问题 -
runtime.ReadMemStats中重点关注HeapAlloc、HeapInuse、NumGC三个字段，别只盯 CPU - 压测时每秒请求量翻倍，GC 次数也翻倍？那基本是 handler 里 new 对象没复用
-gcflags="-m -m" 输出怎么看才不被误导？
逃逸分析输出里最该盯的是 “escapes to heap” 出现的位置和原因。常见陷阱：
-
func() string { return fmt.Sprintf(...) }——fmt.Sprintf内部必然逃逸，改用strings.Builder+WriteString -
return []byte(s)—— 字符串底层数组被直接暴露，强制逃逸；若只读，用unsafe.String转换（Go 1.20+） -
ctx = context.WithValue(ctx, key, bigStruct{})——bigStruct{}会随 ctx 一起逃逸到堆，且生命周期拉长 -
make([]int, 0, 1024)在循环里反复 new —— 即使容量固定，每次调用都算新分配；应提前声明并reslice
Kubernetes 环境下 GOMEMLIMIT 怎么设才不 OOM？
容器 resources.limits.memory 是宿主机 cgroup 限制，Go 运行时看不见它。不设 GOMEMLIMIT，GC 仍按默认逻辑估算目标堆，极易触发 OOMKilled。
立即学习“go语言免费学习笔记（深入）”；
- 设值必须比 limit 小：比如 limit=2Gi，
GOMEMLIMIT=1900Mi（留 100Mi 给 runtime 元数据、goroutine 栈、mmap 映射区） -
GOMEMLIMIT和GOGC共存时，谁先到谁触发；设了GOMEMLIMIT后，GOGC实际影响范围会收窄——比如原本GOGC=100触发点是 2GB，现在可能 1.8GB 就因内存硬限提前 GC - 用
go version确认 ≥ Go 1.19，旧版本不支持GOMEMLIMIT，设了也无效
sync.Pool 用错比不用还糟，哪些操作必须做？
sync.Pool 不是缓存，是“短期对象回收加速器”。Put 前不 Reset、Get 后不归还、跨作用域持有，都会让对象滞留堆中，变成 GC 新负担。
- 所有
bytes.Buffer类型池，Get()后第一行必须是buf.Reset()，否则残留内容会隐式扩容并逃逸 - 不要把
sync.Pool.Get()返回的对象塞进context.WithValue()或全局 map —— 生命周期脱离 Pool 控制，等于泄漏 -
New函数返回指针类型（如&MyStruct{}），但结构体字段含 slice 或 map 时，需在Reset()里清空它们，否则底层数组不会复用 - 池对象不能有 finalizer，否则 GC 无法回收，
runtime.SetFinalizer和sync.Pool天然互斥
真正卡住人的从来不是 GOGC 调多少，而是逃逸分析没跑、GOMEMLIMIT 没配、sync.Pool 的 Reset() 忘写了——这三处漏掉任意一个，调参都是白忙。
