go test -bench 不能真实反映HTTP接口吞吐，因httptest.NewRecorder绕过TCP、TLS、连接池等关键环节，仅测handler内存逻辑；真压测需用vegeta/hey等工具并配合pprof诊断。
用 go test -bench 压测 HTTP 接口？别信它能反映真实吞吐
很多人写个 BenchmarkHTTPHandler 就以为压测完了，结果上线一跑就崩——因为 httptest.NewRecorder() 绕过了 TCP 握手、TLS、连接池、反向代理、甚至 net/http 的 server loop，只测了 handler 函数那一小段逻辑。
- 它适合验证加解密、JSON 序列化、缓存命中路径等纯内存操作
- 一旦涉及数据库查询、HTTP 外调、中间件链路，
-bench测出的ns/op和生产 QPS 完全不相关 - 禁用
time.Sleep：它会阻塞整个B.N循环，让延迟虚高；禁用log.Printf：I/O 会严重干扰计时 - 若真要用，必须加
b.ResetTimer()排除初始化开销，并用-benchmem看Allocs/op，GC 频繁时ns/op毫无意义
手写 goroutine 压测脚本，最常踩的三个资源坑
自己用 net/http + sync.WaitGroup 起协程看似简单，但本地跑着跑着就卡住、报 dial tcp: lookup xxx: no such host 或 too many open files——基本是没管住底层资源。
-
DNS 缓存：默认http.DefaultTransport会缓存 DNS 结果，压测中途换 IP 就失败；解决：提前预热或禁用缓存：http.DefaultTransport.(*http.Transport).DialContext = fastDialer -
连接复用：不设MaxIdleConns和MaxIdleConnsPerHost（建议 ≥1000），连接池耗尽后所有 goroutine 卡在connect状态 -
本地端口耗尽：Linux 默认临时端口仅约 32K，压测超 2 万并发前必须调大：sysctl -w net.ipv4.ip_local_port_range="1024 65535"
vegeta vs hey：选哪个工具取决于你是否需要 JSON 报告和阶梯加压
vegeta 和 hey 都是 Go 写的命令行压测工具，但定位不同。别只看“都是并发发请求”，关键差异在输出粒度和扩展能力。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
vegeta：支持-ramp（渐进加压）、自定义 header/body、JSON 输入、vegeta plot生成图表；适合 CI 回归、基线比对、API 链路测试；安装：go install github.com/tsenart/vegeta@latest -
hey：输出更贴近运维视角（P90/P99 直方图、失败率分布清晰），启动快、二进制小，但不支持负载递增；适合快速摸底、现场排查；安装：go install github.com/rakyll/hey@latest - 共同注意点：都需加
-disable-keepalive（即req.Close = true），否则服务端的TIME_WAIT和accept队列问题会被掩盖
压测中 pprof 不采，等于白压
只看 QPS 和平均延迟，就像只量体温不管血常规——你根本不知道慢在哪。Go 自带的 pprof 是唯一能直接关联到代码行的诊断工具，但必须边压边采，且采法要对。
立即学习“go语言免费学习笔记（深入）”；
- 服务端启动时导入
_ "net/http/pprof"，压测中执行：curl "http://localhost:6060/debug/pprof/profile?seconds=30" > cpu.pprof - 用
go tool pprof cpu.pprof看热点函数；用go tool trace查 goroutine 阻塞、GC STW、系统调用等待 - 重点盯三项：
mutexprofile（锁竞争）、blockprofile（channel 或 I/O 阻塞）、goroutine（泄漏或堆积）
三次压测取中位数、每次清 Redis 缓存、重启服务、手动触发两次 runtime.GC()，这些不是仪式感——是让数据可比的底线。
