Go HTTP 客户端并发请求被串行化怎么办

Go 里启动了很多 goroutine，并不代表同一个目标主机会立刻建立同样多的并行连接。如果 http.Transport.MaxConnsPerHost 设置得很小，超过连接预算的请求会在 Transport 内等待；如果只是把 MaxIdleConnsPerHost 调大，解决的主要是空闲连接复用，不是活动请求的总上限。

官方入口：https://pkg.go.dev/net/http#Transport。这篇只讨论同一主机上的连接预算与排队，不把静态结构图当作压测截图，也不把调大连接数当成服务端一定能承受的结论。

先分清连接上限和空闲连接

我遇到过一种很容易误判的现象：调用方已经并发提交请求，但耗时几乎按几个一组增长。先看 Transport 的三个概念：MaxConnsPerHost 限制每个主机的总连接数，包含正在拨号、活动中和空闲的连接；超过限制时，新的拨号会等待。值为 0 表示不设这个限制。

MaxIdleConnsPerHost 只决定每个主机最多保留多少条空闲 keep-alive 连接；它影响后续请求能否复用已有连接，不等于允许多少个请求同时占用连接。MaxIdleConns 则是所有主机合计的空闲连接上限，三个参数的统计范围不同，不能混用。

因此排查时先问“请求是在等待连接槽位，还是已经发到服务端后变慢”。前者才直接指向 MaxConnsPerHost；后者还可能是服务端处理、网络或响应体读取，不能只改客户端参数。

把并发请求交给可复用的 Transport

官方文档建议复用 Transport，Client 也可以安全地被多个 goroutine 并发使用。把 Client 放在每次函数调用里新建，容易让连接复用失去意义；同时，连接上限也应跟着实际目标主机和服务端承载来设定。

package httpx

import (
    "context"
    "io"
    "net/http"
    "time"
)

// NewClient 复用一个 Transport，并把每个目标主机的连接预算写在同一处。
// 数值只是示例，生产环境要结合服务端限流、连接延迟和请求耗时调整。
func NewClient() *http.Client {
    tr := &http.Transport{
        MaxConnsPerHost:     32, // 限制拨号中、活动中和空闲连接的总数
        MaxIdleConns:        64, // 所有主机合计的空闲连接上限
        MaxIdleConnsPerHost: 16, // 单个主机保留的空闲连接上限
        IdleConnTimeout:     90 * time.Second,
    }
    return &http.Client{
        Transport: tr,
        Timeout:   8 * time.Second, // 覆盖一次请求的总时长
    }
}

// DoJSONLike 演示请求结束后及时关闭响应体，避免连接不能回收到池里。
func DoJSONLike(ctx context.Context, client *http.Client, url string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return err
    }
    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close() // 释放响应体；需要复用时先读取到业务边界
    _, err = io.Copy(io.Discard, resp.Body)
    return err
}

这里的关键不是“32 一定正确”，而是让连接预算、总请求超时和响应体生命周期在同一个客户端配置里可见。响应体不关闭，或读取到一半就丢弃，都会让连接复用和并发观察变得不稳定；连接数调大也不能修复资源没有释放的问题。

用三层判断是否真的被串行化

第一层看客户端：是否共用同一个 Client，是否人为给每个请求加了全局锁，是否把 MaxConnsPerHost 设成了 1。第二层看连接：等待时间是否集中在连接建立或连接槽位，空闲连接数量是否长期不足。第三层看远端：服务端是否主动限流、处理时间是否变长、HTTP/2 是否改变了连接与流的关系。

如果把上限从 1 调到 32 后等待明显下降，说明原配置确实形成了连接瓶颈；但这不代表应该继续无上限增加。连接数上升会带来更多握手、服务端并发和本地文件描述符压力，最终可能只是把排队从客户端挪到服务端。

几个容易混淆的问题

把 MaxIdleConnsPerHost 调大就能解除排队吗？通常不能。它主要管理空闲 keep-alive 连接；活动连接总量受 MaxConnsPerHost 约束时，应先看总连接预算。

每个 goroutine 创建一个 Client 会更快吗？不应把它当成默认优化。Transport 应复用，多个 goroutine 可以共享 Client；只有隔离代理、证书或生命周期等明确边界时才考虑不同 Transport。

为什么上限调大后吞吐仍不变？瓶颈可能已经转移到服务端处理、带宽、响应体读取或业务锁。客户端并发只是资源关系的一层，不是吞吐保证。

可以把判断顺序记成一句话：先确认是否共用 Transport，再区分活动连接上限与空闲连接上限，最后把客户端等待和服务端处理分开看。这样调参才不会把“排队位置变化”误认为“系统真正变快”。

参考：net/http.Transport 官方文档；net/http.Client 官方文档；Go 官方 Transport 源码。