go test -bench 测不出真实 HTTP 延迟，因其默认单 goroutine 运行、不走完整网络栈；需用 httptest 启服务、自控 goroutine 并显式管理连接复用与生命周期。
为什么 go test -bench 测不出真实 HTTP 延迟？
因为默认的 Benchmark 函数运行在单 goroutine 中，且不走网络栈——它测的是你代码的纯逻辑开销，不是客户端发请求、服务端响应、TCP 建连、TLS 握手这一整套链路。如果你直接在 BenchmarkXxx 里调用 http.Get，结果会严重受本地 DNS 缓存、连接复用、Go 的 http.Transport 默认配置（如 MaxIdleConns）影响，和线上压测工具（如 wrk、hey）结果偏差极大。
真正要模拟并发 HTTP 负载，得自己构造 client + goroutine 控制 + 显式管理连接生命周期：
-
http.Client必须复用，但要禁用长连接或控制 idle 连接数，否则 benchmark 会“越跑越快” - 每个 goroutine 应该独立发请求，避免共享
time.Now()或共用sync.Pool引入干扰 - 务必用
b.ReportAllocs()和b.SetBytes(n)标记有效负载大小，否则ns/op没可比性
如何写一个可复现的 HTTP Benchmark 函数？
核心是把“启动服务”和“发起压测”拆开：服务用 httptest.NewUnstartedServer 启动，压测用固定 goroutine 数 + 固定请求数，绕过 Go test 的串行执行限制。示例中用 10 个 goroutine 并发打 1000 次：
func BenchmarkHTTPHandler(b *testing.B) {
srv := httptest.NewUnstartedServer(http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
w.WriteHeader(200)
w.Write([]byte("ok"))
}))
srv.Start()
defer srv.Close()
client := &http.Client{
Transport: &http.Transport{
MaxIdleConns: 0, // 关闭连接复用
MaxIdleConnsPerHost: 0,
},
}
b.ResetTimer()
b.ReportAllocs()
for i := 0; i < b.N; i++ {
var wg sync.WaitGroup
for g := 0; g < 10; g++ {
wg.Add(1)
go func() {
defer wg.Done()
_, _ = client.Get(srv.URL)
}()
}
wg.Wait()
}
}
注意：MaxIdleConns: 0 是关键，否则前几次请求快，后面全走复用连接，ns/op 会虚低；b.ResetTimer() 必须在服务启动、client 初始化之后调用，否则初始化耗时会计入基准。
立即学习“go语言免费学习笔记（深入）”；
net/http/httptest 和真实 server 的性能差异在哪？
httptest.NewServer 底层用的是内存管道（net.Pipe），完全绕过 TCP/IP 协议栈和系统 socket，所以它测的是 handler 逻辑 + Go HTTP 解析器的开销，不是网络延迟。它适合验证 handler 正确性、中间件吞吐量，但不能替代对真实部署环境（Nginx + TLS + 网络抖动）的压测。
如果你发现 httptest 下 QPS 是 50k，但用 hey -n 10000 -c 100 http://localhost:8080 只有 8k，大概率是：
- 真实 server 开了 TLS，加解密吃 CPU
- 操作系统层面的 TIME_WAIT 连接堆积（尤其短连接场景）
- Go runtime 的
GOMAXPROCS设置不合理，或没启用GOEXPERIMENT=fieldtrack（1.22+）优化 GC
什么时候该放弃 go test -bench 改用外部工具？
当你需要以下任一能力时，go test 就不够用了：
- 模拟真实客户端行为：带 Cookie、JWT、随机 User-Agent、阶梯式增压（ramp-up）
- 测量 P95/P99 延迟分布，而不仅是平均
ns/op - 跨机器压测（比如从另一台云服务器打你的服务），涉及 NAT、防火墙、跨 AZ 延迟
- 观察系统指标：CPU、内存、goroutine 数、GC pause —— 这些
pprof能看，但go test不提供实时聚合视图
这时候直接用 hey 或 wrk 更实际。例如：hey -z 30s -c 50 -m POST -H "Content-Type: application/json" -d '{"id":1}' http://your-api.com/v1/item，再配合 go tool pprof http://localhost:6060/debug/pprof/profile?seconds=30 抓 CPU profile。
真正难的从来不是写 benchmark，而是定义清楚：你在测什么——是 handler 逻辑？序列化开销？TLS 性能？还是整个服务链路？选错工具，结论就偏了。
