压测前必须确认API的三个特征：一是Content-Type是否为application/json，否则可能被400拦截；二是是否依赖session或token，因CookieJar默认为空会导致无法复用登录态；三是接口是否幂等，非幂等接口如POST/order会引发数据爆炸。
压测前必须确认的三个 API 特征
Go 做 API 压测不是写个 http.Post 循环就完事——API 的实际行为会直接决定你压测结果是否可信。重点看这三点：
-
Content-Type是否为application/json？若后端严格校验，发text/plain会被 400 拦截，但 Go 默认不设 header，容易漏 - 是否依赖 session 或 token？用
http.Client复用时，CookieJar默认为空，每次请求都是“新用户”，压不出真实登录态下的并发瓶颈 - 接口是否幂等？比如
POST /orders每次都创建订单，压测一跑完数据库就爆了——得先确认能否走GET /health或带固定id的查询类接口
用 net/http + sync.WaitGroup 实现可控并发
别碰第三方压测库（如 vegeta）封装太深，调试时连超时是 DNS 还是 TCP 都分不清。原生组合最稳：
client := &http.Client{
Timeout: 5 * time.Second,
}
var wg sync.WaitGroup
for i := 0; i < 100; i++ {
wg.Add(1)
go func() {
defer wg.Done()
resp, err := client.Get("https://api.example.com/health")
if err != nil {
// 记录 err.Error()，别只打 "failed"
return
}
resp.Body.Close() // 必须关，否则 fd 耗尽
}()
}
wg.Wait()
- 并发数别硬写死循环次数——用
runtime.GOMAXPROCS(0)参考值，但最终以压测目标 QPS 为准（比如要压 200 QPS，就每秒启 200 goroutine） -
http.Client.Timeout是整个请求生命周期，含 DNS、连接、TLS、读响应；若需更细粒度控制，用context.WithTimeout包裹req.Context() - 漏掉
resp.Body.Close()会导致连接不复用，http.Client底层的连接池失效，很快触发dial tcp: lookup xxx: no such host
如何捕获真实失败原因而非笼统的 “timeout”
Go 默认错误信息太模糊，context deadline exceeded 可能是 DNS 卡住、TCP 连不上、TLS 握手失败、或服务端真卡住。得拆开看：
- 加 DNS 日志：在
http.Client.Transport里替换DialContext，用net.Resolver手动解析并计时 - 区分连接超时和读超时：自定义
http.Transport，设DialContext: (&net.Dialer{Timeout: 1 * time.Second}).DialContext和ResponseHeaderTimeout: 2 * time.Second - 检查状态码分布：别只统计 “成功/失败”，用
map[int]int记录resp.StatusCode，突然大量 429 或 503 比单纯 timeout 更说明问题
避免 Goroutine 泄漏的两个硬约束
压测脚本跑完进程不退，十有八九是 goroutine 没收干净。盯死这两处：
- 所有
go func() { ... }()必须配defer wg.Done()，且wg.Wait()后不能有阻塞操作（比如没关闭的 channel receive） - 用
http.Client时禁用长连接：设Transport.MaxIdleConnsPerHost = 0，否则压测结束时 idle 连接还挂着，pprof/goroutine里能看到一堆transport.dialConn
复杂点在于：真实压测要持续几分钟甚至小时，中间可能需要动态调速、采样日志、熔断失败率——这些逻辑一旦掺进 goroutine，泄漏概率指数上升。建议把压测主循环抽成独立函数，用 select + time.After 控制生命周期，别靠 sleep 硬等。
