QPS上不去主因是连接卡死、内存拖垮、goroutine堆积或超时未设：http.Client未复用致连接池失效；resp.Body未关闭致fd耗尽；goroutine泛滥且无控速引发调度崩溃；不使用pprof盲目优化。
QPS上不去，八成不是代码写得慢，而是连接卡死、内存被拖垮、goroutine堆满或超时没设对——这些地方一堵，再快的逻辑也出不去。
http.Client没复用，连接池形同虚设
每次请求都 http.Client{} 新建一个 client，等于每次新建一套独立的 http.Transport。你配的 MaxIdleConns、IdleConnTimeout 全部失效，底层 TCP 连接反复建连释放，DNS 解析还可能阻塞在 goroutine 里。
- 现象：
too many open files、dial tcp: lookup xxx: no such host、大量net/http: request canceled (Client.Timeout exceeded) - 正确做法：全局单例复用一个
*http.Client，它本身是并发安全的 - 典型错误配置：
http.DefaultClient被多个模块共用，某处改了 Transport 就影响全局
响应体没读完也没关，连接永远回不了池子
resp, err := client.Do(req) 后只判 err != nil 就 return，完全忽略 resp 是否非 nil；或者压根不碰 resp.Body。结果连接卡在 CLOSE_WAIT 或 TIME_WAIT，fd 持续增长，几分钟后直接 too many open files。
- 必须做：
defer resp.Body.Close()，哪怕err != nil也要先检查resp是否非 nil - 如果只关心状态码，至少要消费掉 body：
io.Copy(io.Discard, resp.Body)或ioutil.ReadAll(resp.Body) - 别信“我用的是短连接”，HTTP/1.1 默认 keep-alive，不读 body 就不算完成一次请求
goroutine 泛滥 + 没控速，调度器先扛不住
一个请求启动 50 个 goroutine 去并发调下游，1000 QPS 就是 5w goroutine。它们未必真在干活，很多卡在 DNS、TLS 握手、TCP connect 或没设 timeout 的 http.Get 上——内存暴涨、GC 频繁、调度延迟飙升，QPS 反而断崖下跌。
立即学习“go语言免费学习笔记（深入）”；
- 用
errgroup.Group或带缓冲的 channel 控制并发数，比如最多同时 10 个 HTTP 请求 - 所有外部调用必须带
context.WithTimeout，超时时间 ≤ 你自身接口 SLA（如整体要求 ≤200ms，则下游设 ≤150ms） - 避免在 handler 里
go func() { ... }()不加管控，worker pool 比裸起 goroutine 更可控
没 profile 就调优，纯属蒙眼修车
看日志说“慢”，但不知道是卡在 DNS、TLS、TCP connect、服务端处理，还是 JSON 解析、GC、锁竞争？不跑 go tool pprof，所有优化都是拍脑袋。
- 上线前必开：
import _ "net/http/pprof"，暴露/debug/pprof/ - 压测中采样：
go tool pprof http://localhost:6060/debug/pprof/profile（CPU）、heap（内存）、goroutine（协程堆积） - 特别注意
block和mutexprofile，它们能揪出隐藏的锁等待和 channel 阻塞
真正卡 QPS 的，往往不是算法或业务逻辑，而是那些默认值、忘记关的 Body、没设 timeout 的 client、以及从不看 pprof 的习惯。
