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 初始化之后调用，否则初始化耗时会计入基准。
net/http/httptest 和真实 server 的性能差异在哪？
httptest.NewServer 底层用的是内存管道（net.Pipe），完全绕过 TCP/IP 协议栈和系统 socket，所以它测的是 handler 逻辑 + Go HTTP 解析器的开销，不是网络延迟。它适合验证 handler 正确性、中间件吞吐量，但不能替代对真实部署环境（Nginx + TLS + 网络抖动）的压测。
