runtime.GC()必须放在b.ResetTimer()前，是为了强制回收上一轮残留堆压力，避免STW干扰计时；若在其后调用，GC耗时会被计入ns/op导致虚高，且需配合debug.SetGCPercent(-1)禁用后续自动GC。
Go 基准测试结果在 GC 干扰下基本不可信，不手动干预 GC 行为就跑 go test -bench，等于拿噪声当信号。
为什么 runtime.GC() 必须放在 b.ResetTimer() 前
GC 可能在任意时刻触发，尤其当上一轮 Benchmark 留下未回收对象时，下一轮刚启动就遭遇 STW 或标记开销，ns/op 波动剧烈。直接调用 runtime.GC() 强制回收上一轮残留，是唯一能清空堆压力的手段。
-
b.ResetTimer()之后发生的 GC 会被计入耗时，导致结果虚高；必须在它之前完成清理 - 单次
runtime.GC()不够——要等它真正完成，需配合debug.SetGCPercent(-1)禁用后续自动 GC - 若被测函数本身触发大量分配（如频繁
make([]byte, n)），仅靠一次 GC 仍可能在循环中再次触发，此时必须预分配+复用
debug.SetGCPercent(-1) 的真实作用和风险
这不是“关闭 GC”，而是把 GC 触发阈值设为负数，让运行时跳过自动触发逻辑。它只影响 GC 的“启动条件”，不影响已进入标记阶段的流程或手动调用的 runtime.GC()。
- 设为
-1后，GC 不再因堆增长自动启动，但内存仍在增长，allocs/op会持续累积，直到你显式调用runtime.GC()或进程退出 - 若忘记恢复（比如没在
defer中重置），后续测试或主程序可能因内存爆涨 OOM - 它不能替代预分配：禁用 GC 只是掩盖分配问题，不减少实际内存占用，
B/op和allocs/op依然会暴露瓶颈
什么时候该用 GOMEMLIMIT 而不是 GOGC
GOGC 控制的是“上一次 GC 后堆增长多少百分比就触发下一次”，而 GOMEMLIMIT 是硬性上限（字节级），更适用于容器化部署和内存敏感场景。
-
GOGC=100在 1GB 堆时允许增长到 2GB 才 GC，但若容器内存 limit 是 1.2GB，就会 OOM；GOMEMLIMIT=1.1e9则强制在 1.1GB 触发 GC，更可控 -
GOMEMLIMIT优先级高于GOGC，设了前者后者自动失效 - 基准测试中若想模拟生产内存压力，应在
go test命令前加环境变量：GOMEMLIMIT=536870912 go test -bench=. -benchmem
go test -bench 默认参数怎么悄悄毁掉你的对比结果
不显式指定关键参数，go test 就按默认行为跑，而默认值对严谨对比极不友好。
-
-count=1：单次运行受 CPU 频率抖动、后台进程干扰极大，ns/op可能偏差 30% 以上；至少用-count=5，再人工剔除离群值 -
-benchtime=1s：短函数（如纯计算）可能只跑了几十次就被截断，b.N过小导致统计失真；应设为-benchtime=3s或更长 - 不加
-benchmem：看不到allocs/op，根本无法判断性能退化是否来自隐式扩容（比如strings.Builder.WriteStringvsfmt.Sprintf）
真正难的不是写对 b.N 循环，而是确认你压测的路径和生产一致：是否用了相同的数据规模、是否复用了缓冲区、是否关掉了 GODEBUG=gctrace=1 这类调试开关。漏掉其中任何一项，Benchmark 就只是自洽的幻觉。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
