GolangQPS瓶颈分析与优化技巧

Golang服务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 反而断崖下跌。

• 用 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 和 mutex profile，它们能揪出隐藏的锁等待和 channel 阻塞

真正卡 QPS 的，往往不是算法或业务逻辑，而是那些默认值、忘记关的 Body、没设 timeout 的 client、以及从不看 pprof 的习惯。

以上就是《GolangQPS瓶颈分析与优化技巧》的详细内容，更多关于的资料请关注golang学习网公众号！