默认 Client 能否直接用于高并发服务，连接池边界怎么判断

可以直接用于并发请求：http.DefaultClient 和它背后的 http.DefaultTransport 都支持多个 goroutine 并发使用，而且官方明确建议复用 Client 与 Transport。但“并发安全”只说明共享使用不会因为内部状态而天然产生数据竞争，并不表示它已经替你设置了请求总超时、上游连接上限，也不表示默认的空闲连接容量适合持续高并发。

我处理这类配置时，会先把问题拆成三层：请求能等多久、同一上游最多允许多少连接、请求结束后保留多少空闲连接。三层边界都清楚以后，才决定继续使用默认 Client，还是为服务创建一个长期复用的专用 Client。

官方地址：https://pkg.go.dev/net/http

并发安全不是生产边界已经合理

http.DefaultClient 的优势是可以立即使用，并且不会为每个请求重新创建一套 Transport。对简单脚本、低频后台任务，或者请求本身已经有明确 context 截止时间的场景，这通常足够。

真正容易被忽略的是：默认 Client 的 Timeout 为零，也就是没有客户端级总超时。上游连接、响应头或响应体只要一直没有结束，请求就可能一直占着 goroutine 和连接。另一方面，默认 Transport 虽然能缓存连接，但它不会主动替业务建立“最多只允许 N 个请求同时打向某个上游”的保护边界。

默认连接池的 2 不是并发只能为 2

这是我最常见到的误读。DefaultMaxIdleConnsPerHost = 2 限制的是“每个主机最多保留多少条空闲 keep-alive 连接”，不是“同时最多发两个请求”。默认的 MaxConnsPerHost 为零，含义是拨号中、活跃和空闲连接的总数不受这个字段限制。

因此，高并发到来时，默认 Transport 仍然可以继续建立连接。问题通常发生在流量波峰过去以后：每个主机只保留很少的空闲连接，下一波请求可能重新拨号和握手。访问很多不同主机时，还要同时关注全局空闲连接数量与空闲超时。HTTPS 上如果协商到 HTTP/2，一条连接还能复用多个并发流，所以“请求并发数等于 TCP 连接数”的估算也会失真。

响应体没有收好，连接池参数再大也可能白调

连接能否回到可复用状态，还取决于调用方如何处理 Response.Body。官方文档强调：响应体需要读取到 EOF 并关闭，否则底层 Transport 可能无法把持久连接用于后续请求。只写 defer resp.Body.Close() 却在中途放弃读取大响应，也应结合业务决定是否主动丢弃连接，而不是假设它必然回池。

resp, err := client.Do(req)
if err != nil {
    return err
}
defer resp.Body.Close() // 确保函数退出时释放响应体

// 按业务上限读取，避免无界响应占满内存；完整读到 EOF 才更有利于连接复用
body, err := io.ReadAll(io.LimitReader(resp.Body, 2

如果接口可能返回超过限制的正文，上面的示例会在到达限制后停止，连接未必能复用。这不是代码错误，而是资源保护与连接复用之间的取舍。更稳妥的做法是根据响应协议设置合理上限，并让异常大响应快速失败。

高并发服务更适合克隆默认 Transport 再加边界

我通常不会从零手写 Transport，因为容易漏掉代理、拨号、TLS 握手、HTTP/2 尝试等默认行为。更稳妥的方式是克隆 http.DefaultTransport，只覆盖当前服务确实需要改变的字段，然后让一个长期存在的 Client 复用它。

package upstream

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

func NewClient() *http.Client {
    // 克隆默认 Transport，保留代理、拨号和协议协商等标准行为
    tr := http.DefaultTransport.(*http.Transport).Clone()
    tr.MaxIdleConns = 200
    tr.MaxIdleConnsPerHost = 80
    tr.MaxConnsPerHost = 120
    tr.IdleConnTimeout = 90 * time.Second
    tr.ResponseHeaderTimeout = 3 * time.Second
    tr.DialContext = (&net.Dialer{
        Timeout:   2 * time.Second,  // 限制建立连接的等待时间
        KeepAlive: 30 * time.Second, // 保持 TCP 存活探测配置
    }).DialContext

    return &http.Client{
        Transport: tr,
        Timeout:   5 * time.Second, // 覆盖连接、重定向和读取响应体的总时间
    }
}

示例里的 200、80、120 不是通用答案，只是展示三个边界的职责：MaxIdleConns 管全部主机的空闲连接，MaxIdleConnsPerHost 管单个主机的空闲保有量，MaxConnsPerHost 管单个主机拨号中、活跃和空闲连接的总量。触达总量上限时，新拨号会等待可用容量。

如果不同上游的延迟、容量和故障隔离要求差异很大，我倾向于为每类上游创建独立 Client，而不是共享一个全局池。这样慢供应商不会挤占核心依赖的连接预算，超时和熔断策略也更容易按依赖设置。

连接池边界要从流量和延迟反推

对 HTTP/1.1 上游，可以先用“小范围估算”起步：稳定期需要的活跃连接数量大致与每秒请求量乘以平均请求耗时相关。例如 500 QPS、平均 100 毫秒，平均同时在途请求约为 50。这个数字只是容量起点，还要给延迟抖动、突发流量和重试留下余量。HTTP/2 存在多路复用时，应直接观察连接与流数量，不要套用一请求一连接。

我会同时观察下面几类信号，而不是只看 QPS：

• 新建连接速率、TLS 握手速率是否在每次波峰重复升高；
• 每个上游的在途请求、排队等待和超时比例；
• 空闲连接数量、连接复用率与空闲关闭数量；
• 进程文件描述符、本机临时端口与上游允许连接数；
• HTTP/1.1 与 HTTP/2 的实际协议占比。

MaxIdleConnsPerHost 太小，常见后果是突发结束后大量连接被丢弃，下一波重新握手；太大则会长期占用文件描述符和上游资源。MaxConnsPerHost 太小会让请求在客户端排队，太大又可能把上游压垮。它们不是越大越好，而是要让连接复用、排队时间和资源预算同时处于可接受区间。

什么时候可以继续用默认 Client

下面是我最终采用的判断清单：

• 可以继续用默认 Client：低频请求、短生命周期工具、请求自带明确 Context 截止时间、对单主机连接隔离没有要求。
• 应该创建专用 Client：常驻服务、高并发调用、需要统一总超时、需要限制单个上游连接数、多个上游必须隔离资源预算。
• 必须先修调用方式：每次请求都新建 Transport、响应体未关闭、没有读取边界、请求没有取消路径。
• 参数需要压测后再定：目标主机数量、HTTP 协议、延迟分布、QPS、上游限额和机器资源尚不明确。

一句话收束：默认 Client 能扛并发，但它不是自动完成容量规划的连接池。先长期复用，再补齐请求生命周期与每主机容量边界，最后用真实服务指标调整，才是高并发场景下更稳妥的做法。

相关问题

每个 goroutine 都创建一个 http.Client 会更快吗？

通常不会。Client 和 Transport 本来就支持并发复用；频繁创建会拆散连接池，增加拨号与握手开销。更常见的模式是按上游或策略复用少量长期 Client。

只设置 MaxIdleConnsPerHost 就能限制并发吗？

不能。它只限制每主机保留的空闲连接。要限制拨号中、活跃和空闲连接总量，应使用 MaxConnsPerHost，并结合应用层并发控制与超时。

Client.Timeout 和 Context 超时应该同时设置吗？

可以。Client.Timeout 适合作为该客户端的总保护上限；请求 Context 适合表达一次调用链更短、更具体的截止时间。实际生效的是更早触发的取消条件。

服务退出时要调用 CloseIdleConnections 吗？

长生命周期服务正常退出时可以调用它主动关闭当前空闲连接；它不会中断正在使用的活跃连接。短命令工具通常会随进程退出一起释放资源。