golang吞吐量低怎么办

Go 服务吞吐量上不去，很多人的第一反应是改业务逻辑——其实，真正卡脖子的地方，往往不在代码本身，而在连接管理、超时控制和并发调度上。先说个结论：吞吐量低，八成不是代码写得慢，而是连接没复用、超时没控好、goroutine 没管住。

所以，先别急着优化业务逻辑，盯紧 http.Server 和 http.Transport 的几个关键字段，往往就能立竿见影。

http.Server 启动时，必须显式设置这 4 个超时参数

默认不设超时，一个慢请求就能卡住整个连接池，QPS 断崖式下跌。现象很典型：用 netstat -an | grep :8080 | wc -l 看连接数很高，但 CPU 占用率却很低；再用 ss -s 一看，大量 ESTABLISHED 连接堆积在那里，既没释放也没干活。

• ReadTimeout：从 TCP 建连到读完请求头的上限，建议设为 5 * time.Second。如果涉及大文件上传，可以单独用 ReadHeaderTimeout 分别控制。
• WriteTimeout：从开始写响应到写完的上限，建议 10 * time.Second。这能防止 handler 卡在 DB 查询或日志写入里，迟迟不返回。
• IdleTimeout：Keep-Alive 空闲连接的最长存活时间。这个必须设，比如 30 * time.Second，否则 fd 会迅速耗尽。
• MaxHeaderBytes：防攻击用的，设为 64 （64KB） 比较安全。

别再用 http.DefaultClient 发下游请求了

它的 MaxIdleConnsPerHost 默认只有 2，这在多域名高频调用场景下，连接池秒空，后续请求只能排队等连接，延迟毛刺非常明显。

• 每个下游目标应该配一个独立的 *http.Client 实例，transport 中设 MaxIdleConns ≥ 200、MaxIdleConnsPerHost ≥ 100。
• IdleConnTimeout 设为 60 * time.Second 左右。太短失去复用价值，太长又容易积压失效连接。
• 务必禁用 ExpectContinueTimeout（设为 0），否则小请求会卡在 100-continue 等待上，白白浪费时间。
• 全局复用 client 实例，禁止在 handler 里每次 new(http.Client)，那会频繁创建连接和销毁，性能极差。

goroutine 不是越多越好，得用池控住

每请求起一个 goroutine，在高并发下会迅速拉高 runtime.NumGoroutine()，调度器过载，P99 延迟飙升。用 pprof 看一下，runtime.mallocgc 占比常超 40%——这就是没有池化，没有控制的结果。

• 用 ants 或自建 worker pool，初始大小按 runtime.GOMAXPROCS(0) * 2 ~ 4 压测调整。
• 任务 channel 必须带缓冲，比如 make(chan Task, 1000)，否则生产者一卡，吞吐直接归零。
• 每个 worker 内必须用 select 主动响应取消，不能只靠超时。
• DB 查询、HTTP 调用等 I/O 全部走 ctx，例如 db.QueryContext(ctx, sql)，确保上下文传递完整。

别忘了系统级参数和连接队列

Go 层面调优再细，如果 /proc/sys/net/core/somaxconn 还是 128，客户端照样收 Connection refused。细节决定成败。

• 启动前执行 sysctl -w net.core.somaxconn=4096，并确认 cat /proc/sys/net/core/somaxconn 输出一致。
• 用 ss -lnt 观察监听端口的 Recv-Q，若持续接近 somaxconn 值，说明连接队列已满，需要扩容。
• 如果用了 net.Listen 拿到 *net.TCPListener，无需手动设置 backlog，系统参数生效即覆盖。
• 容器环境里注意 ulimit -n，避免 fd 不足导致 accept 失败。

真正卡吞吐的地方，往往藏在那些“不起眼”的配置里，比如 http.Transport.IdleConnTimeout 和 net.core.somaxconn。改完记得用 ab 或 hey 对比压测，看 ss -s 和 runtime.NumGoroutine() 是否同步下降——数字不骗人。