GOGC 控制 GC 触发阈值，非简单调数；默认100适合通用服务，高并发宜设30~50以降延迟，批处理可设200；禁用0或负值；GOMEMLIMIT是内存上限保险丝，非节流阀；sync.Pool需正确使用防逃逸；Ballast仅对冷启冲高有效。
怎么调 GOGC 才不算瞎设
调 GOGC 不是改个数字就完事——它控制的是“堆中存活对象大小 × (1 + GOGC/100)”这个阈值，一旦突破就触发 GC。默认 GOGC=100 意味着堆翻倍才扫一次，适合通用服务；但高并发 HTTP 服务里，这常导致内存冲到 2GB 才 GC，停顿突然飙到 3ms+。
- 想压低延迟？试
GOGC=30~50：GC 更勤快，内存峰值稳，但 CPU 占用会上升 10%~20% - 跑离线批处理？
GOGC=200合理：减少 GC 次数，吞吐优先，只要内存够用 - 千万别设
GOGC=0或负数：Go 会静默忽略，退回到默认值，白配 - 代码里动态调用
runtime.SetGCPercent(50)可以生效，但它返回旧值，记得存一下，方便出问题时回滚
GOMEMLIMIT 是保险丝，不是节流阀
它设的是 Go 程序能用的最大堆内存上限（比如 GOMEMLIMIT=1073741824 = 1GB），超了就强制 GC，再超可能直接 OOM。但它不阻止分配，只在 GC 决策时起作用——这点很多人误以为“设了就卡死在 1GB”，其实不是。
- 设太低（如
GOMEMLIMIT=512MB）：GC 频繁触发，CPU 翻倍，反而拖慢请求 - 设太高（如
GOMEMLIMIT=4GB）：和没设一样，失去保护意义 - 推荐值 = 观察线上
MemStats.HeapAlloc的 P95 值 × 1.3，再向上取整到 128MB 倍数 - 必须搭配
GODEBUG=gctrace=1日志看 “12->12->8 MB” 这类三段式堆变化，确认是否真被限住了
为什么 sync.Pool 用了还爆内存
常见错觉：加了 sync.Pool 就万事大吉。实际中，如果 New 函数返回的是大对象、或 Get 后忘了 Reset()、或 Put 前已逃逸到全局，Pool 就形同虚设，甚至因缓存无效对象拖慢 GC。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 切片池别直接
make([]byte, 1024)：预分配容量，但别预填充数据，否则每次 Get 都带“脏内容” - 结构体池要显式清零：
obj := pool.Get().(*Req); obj.Reset() // 必须自己实现 Reset 方法 - 避免闭包捕获大变量：
func() { return buf }中的buf若来自循环外，可能让整个上下文逃逸到堆 - Pool 不保证复用率——空闲超过 5 分钟的对象会被 GC 清掉，高频短周期场景才真正受益
Ballast 内存技巧真能“骗过” GC 吗
Ballast（压舱石）指提前分配一大块 []byte 占着内存，让 Go 的堆起点变高，从而延后首次 GC 触发时机。它确实有用，但只对启动后快速冲高内存的场景有效（比如微服务冷启瞬间打满连接），且副作用明显。
立即学习“go语言免费学习笔记（深入）”；
- 典型写法：
ballast := make([]byte, 200，放在 <code>main()开头，别 global，别 export - 它不减少总分配量，只是把“增长比例”分母拉大，让
GOGC=100实际对应更大堆空间 - 风险很高：K8s 里若未配好
resources.limits，Ballast 会直接触发 OOMKilled - 比 Ballast 更稳的做法是：用
GOMEMLIMIT+GOGC组合控住上限，再靠 pprof 定位真实分配热点
GC 调优最易被忽略的一点：所有参数改动都得有 pprof heap 和 gctrace 日志对照，否则你根本不知道是优化了还是恶化了——尤其是 GOGC 下调后 PauseNs 看似降了，但 NumGC 翻倍，整体 CPU 时间可能反而涨了。
