压测前必须设置GOMEMLIMIT，它是容器中约束Go堆上限的唯一有效参数，建议设为容器内存限制的75%～85%，且优先级高于GOGC；配合GODEBUG=gctrace=1分析GC行为，并通过AB测试确定GOGC最优值，同时正确使用sync.Pool。
压测前必须设好 GOMEMLIMIT，否则所有 GC 调优都是空谈
容器环境（K8s/Docker）下，GOMEMLIMIT 是唯一能真正约束 Go 堆上限的参数。不设它，GOGC 再怎么调，RSS 也会一路涨到被 OOMKilled——因为 Go 默认只看堆增长比例，不看宿主机实际内存压力。
实操建议：
- 设为容器内存限制的 75%～85%，例如
memory: 1Gi→GOMEMLIMIT=800MiB - 单位不区分大小写，
800MB、800MiB、838860800都合法 - 和
GOGC共存时，GOMEMLIMIT优先级更高：哪怕堆只涨了 10%，只要总 RSS 接近上限，GC 就会强制启动 - 别设过低（如
GOMEMLIMIT=512MB在 1GB 容器里），会导致 GC 频繁、CPU 反升；也别设过高（如4GB），等于没设
用 GODEBUG=gctrace=1 看清每次 GC 的真实代价
光看 P99 延迟没用，得知道每次 GC 到底花了多少时间、在哪卡住。GODEBUG=gctrace=1 输出的每行日志都含关键信号，比如：
gc 12 @3.456s 0%: 0.012+0.45+0.008 ms clock, 0.096+0.12/0.28/0.51+0.064 ms cpu, 12->12->8 MB, 13 MB goal
重点关注三段数字：0.012+0.45+0.008 是 STW 标记、并发标记、STW 清扫耗时（单位 ms），加起来就是本次停顿总长；12->12->8 MB 表示标记前堆 12MB、标记后仍 12MB（说明没回收掉）、清扫后剩 8MB；13 MB goal 是下一次 GC 目标。
实操建议：
- 压测中持续采集该日志，用脚本提取
PauseTotal和NumGC，画趋势图 - 若
clock中第二项（并发标记）持续 >1ms，说明标记阶段拖慢，大概率是对象太多或指针链太深 - 若
goal值远高于实测稳定inuse_space（用runtime.ReadMemStats查），说明GOGC设太高了
GOGC 不要凭经验硬设，用 AB 测试找拐点
GOGC=100 是默认值，但不是最优值。它控制的是“堆增长百分比触发 GC”，设高了省 GC 次数但吃内存，设低了省内存但 CPU 升——这个权衡点必须靠压测数据定。
实操建议：
- 先跑 baseline（
GOGC=100），记录 P99 延迟、CPU 使用率、GC Pause 平均值 - 再分别跑
GOGC=75、GOGC=125、GOGC=200三组，每组至少 5 分钟稳态流量 - 重点看两个拐点：①
GOGC提高后，PauseTotal 是否显著下降（如从 8ms→2ms）；② CPU 是否开始明显上升（>15%） - 生产环境永远用环境变量传参（
GOGC=125 ./myapp），别写死在代码里——改个参数还得发版
sync.Pool 不是缓存，用错比不用更伤 GC
sync.Pool 对小对象（≤32KB）有效，但它的生命周期和 GC 强绑定：每次 GC 前会被清空。把它当长期缓存用，只会让对象在池里滞留更久，反而延迟回收。
实操建议：
- 每次
Get()后必须Reset()，比如buf.Reset()，否则下次Put()进去的是带脏数据的对象 - 别把含
context.CancelFunc的结构体放进去，CancelFunc会阻塞 goroutine 泄漏 - 别往 Pool 里扔大对象（如 >1MB 的
[]byte），它对大对象复用收益极低，还占 GC 扫描时间 - 高频路径才值得加 Pool，比如 HTTP handler 里的
*json.Decoder或临时[]byte缓冲区
真正难的不是调哪个参数，而是理解 GC 不是一个“开关”，而是一整套与内存分配速率、对象生命周期、容器资源边界联动的反馈系统。压测时漏掉 GOMEMLIMIT 或者只盯着 GOGC 改，结果往往南辕北辙。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
