Go基准测试需手动控制并发、采集分位数并排除GC/调度干扰：固定goroutine数与总请求数，调用b.ResetTimer()，用runtime.GC()、GOMAXPROCS=1、debug.SetGCPercent(-1)降噪，-benchtime=1000x确保可比性。
Go 的 testing 包原生支持基准测试，但直接用 go test -bench 测“响应时间”容易误读结果——它默认测的是吞吐量（ns/op），不是单次请求的延迟分布。要真实反映服务响应时间，得自己控制请求节奏、采集 P50/P95/P99，并排除 GC 和调度抖动干扰。
用 testing.B 模拟并发请求并记录延迟
标准 BenchmarkXxx 函数在 b.N 次循环中反复调用被测逻辑，但若被测逻辑含 HTTP 请求或 I/O，b.N 会自动调整导致实际并发不可控。正确做法是固定 goroutine 数量 + 固定总请求数 + 显式记录每次耗时：
func BenchmarkHTTPResponseTime(b *testing.B) {
// 预热 client，避免 TLS 握手等首次开销影响
client := &http.Client{Timeout: 5 * time.Second}
url := "http://localhost:8080/health"
<pre class="brush:php;toolbar:false;">b.ResetTimer() // 仅从这行开始计时
b.ReportAllocs()
durations := make([]time.Duration, 0, b.N)
var wg sync.WaitGroup
for i := 0; i < b.N; i++ {
wg.Add(1)
go func() {
defer wg.Done()
start := time.Now()
_, err := client.Get(url)
if err == nil {
durations = append(durations, time.Since(start))
}
}()
}
wg.Wait()
// 手动统计分位数（需排序后取索引）
sort.Slice(durations, func(i, j int) bool { return durations[i] < durations[j] })
b.ReportMetric(float64(durations[len(durations)/2]).Seconds(), "p50-sec")
b.ReportMetric(float64(durations[int(float64(len(durations))*0.95)]).Seconds(), "p95-sec")}
- 必须调用
b.ResetTimer()，否则 client 初始化、切片预分配等准备代码会被计入耗时 - 不要用
b.RunParallel：它按 goroutine 分配迭代次数，无法保证总请求数精确，且不便于收集单次延迟 - 延迟单位统一转成秒（
.Seconds()）再传给b.ReportMetric，否则go test -benchmem输出会混乱
避免 runtime.GC 干扰和调度噪声
基准测试期间若触发 GC 或 goroutine 被抢占，单次延迟会出现尖刺，拉高 P99。需主动干预：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 测试前调用
runtime.GC()+debug.FreeOSMemory()清空堆和操作系统内存页 - 用
GOMAXPROCS=1运行测试，排除多 P 调度竞争（尤其测纯 CPU 逻辑时） - 加
runtime.LockOSThread()锁定当前 goroutine 到 OS 线程，减少上下文切换（仅限单 goroutine 场景） - 禁用后台 GC：
debug.SetGCPercent(-1)，测完再恢复（注意内存泄漏风险）
对比不同实现时，必须固定 b.N 和环境
go test -bench 默认让 b.N 自适应以满足最小运行时间（1 秒），这会导致不同函数的 b.N 值不同，无法直接比 P95。解决方法：
- 强制指定迭代次数：
go test -bench=. -benchmem -benchtime=1000x（注意是x不是s） - 所有对比实验在相同机器、关闭 CPU 频率调节（
sudo cpupower frequency-set -g performance）、无其他负载下运行 - 每个 benchmark 单独跑，避免 cache 预热效应污染下一个测试（
go test -bench=BenchmarkFoo）
真正难的不是写代码打点，而是确认你测的到底是网络栈延迟、TLS 开销、还是业务逻辑本身——得一层层剥离，比如先用 curl -w "@format.txt" 对比，再进 Go 里复现，最后才动 profiler。否则优化了半天，可能只是把 DNS 查询从 20ms 降到 15ms。
