qps上不去主因是http.defaultclient的transport连接池参数过于保守，maxconnsperhost默认仅2，导致并发请求阻塞；需新建client并调大maxconnsperhost、maxidleconns等参数，配合ticker限速、ulimit调优及context超时控制。
用 http.DefaultClient 发起并发请求时，为什么 QPS 上不去？
默认的 http.DefaultClient 底层复用 http.Transport，但它的连接池参数保守：默认只允许 2 个并发连接到同一 host（MaxConnsPerHost = 2），且空闲连接 30 秒后复用失效。压测时大量 goroutine 卡在等待连接，QPS 被硬限在极低水平。
- 必须显式配置
http.Transport，重点调大MaxConnsPerHost（如设为 100 或 0 表示无限制）和MaxIdleConns -
IdleConnTimeout建议设为 90 秒以上，避免频繁建连；TLSHandshakeTimeout加上，防止 TLS 握手卡死整个 goroutine - 别直接改
http.DefaultClient—— 它是全局单例，会影响其他模块；应新建独立http.Client
client := &http.Client{
Transport: &http.Transport{
MaxConnsPerHost: 100,
MaxIdleConns: 100,
IdleConnTimeout: 90 * time.Second,
TLSHandshakeTimeout: 10 * time.Second,
},
}用 sync.WaitGroup 控制并发数，但压测结果波动极大
单纯靠 WaitGroup.Add(n) 启动 n 个 goroutine，看似并发了，实际是“一窝蜂”发起请求，没做速率控制。网络抖动、服务端限流、本地文件描述符耗尽都会导致失败率飙升、RT 毛刺严重，数据不可信。
- 必须引入固定速率（如 RPS），用
time.Ticker驱动每次发请求，而不是一次性拉满 goroutine - goroutine 数量 ≠ 并发连接数；建议 goroutine 数略大于目标 RPS（比如 RPS=500，开 64 个 goroutine），每个 goroutine 循环取
发请求 - 注意
ulimit -n，Linux 默认 1024，压测前至少设为 65535，否则报dial tcp: lookup xxx: no such host或too many open files
http.Request 的 Context 超时设置不生效？
常见错误是只给 http.Client.Timeout，但没传 context.Context 到 client.Do()，或用了 context.Background() 却没设 deadline。结果请求卡住几十秒不返回，压测进程 hang 死。
- 必须用
context.WithTimeout(ctx, reqTimeout)创建带超时的 context，并传给client.Do(req.WithContext(ctx)) -
client.Timeout只控制整个 Do 过程（含 DNS、连接、写请求、读响应头），不包含读响应体；若要限制全文读取，需在Response.Body上手动加io.LimitReader或用http.MaxBytesReader - 别忽略
err类型：网络错误是*url.Error，服务端返回 5xx 是nil err+ 非 2xxresp.StatusCode，二者统计逻辑不同
压测中如何准确统计成功率、P95、QPS？
用 time.Now() 手动打点再排序算 P95，容易因 GC、调度延迟引入毫秒级误差；而每请求都 fmt 打 log 会拖慢 3–5 倍性能，数据也不准。
立即学习“go语言免费学习笔记（深入）”；
- 用
runtime.GC()在压测前手动触发一次，减少压测中 STW 干扰 - 响应时间存进预分配的
[]int64（容量等于总请求数），用sort.Slice()算分位值；避免 map 或 channel 聚合，它们有锁或调度开销 - QPS 不要用 “总请求数 / 总耗时”，而是用滑动窗口：每秒计数器用
atomic.Int64，每秒重置并输出，更反映瞬时压力 - 注意时钟源：Linux 上优先用
time.Now().UnixNano()，别用time.Since()套嵌套，它内部也调Now()
真实压测里最常被跳过的，是服务端日志采样率、客户端 DNS 缓存、以及 TCP TIME_WAIT 占满端口导致新连接失败 —— 这些不会报错，但会让结果看起来“不稳定”。
