默认http.DefaultClient在高并发下易出问题，因其底层http.Transport默认MaxIdleConns和MaxIdleConnsPerHost均为100、IdleConnTimeout为30秒，高并发时连接池耗尽导致请求阻塞或超时。

为什么默认的 http.DefaultClient 在高并发下容易出问题

它底层复用 http.Transport，但默认配置偏保守：MaxIdleConns 和 MaxIdleConnsPerHost 都是 100，IdleConnTimeout 是 30 秒。当并发请求猛增（比如 500+ goroutine 同时发请求），连接池很快耗尽，后续请求会阻塞在 getConn，甚至触发超时或 net/http: request canceled (Client.Timeout exceeded while awaiting headers)。

如何配置自定义 http.Client 提升并发吞吐

关键不是盲目调大数字，而是匹配业务场景：短连接密集型（如调第三方 API）要优先保连接复用；长连接低频（如 Webhook 回调）可适当收紧。推荐配置如下：

• MaxIdleConns 设为 200–500，避免全局连接池瓶颈
• MaxIdleConnsPerHost 至少等于 MaxIdleConns，否则单域名仍受限
• IdleConnTimeout 建议 30–90 秒，太短导致频繁建连，太长占用资源
• TLSHandshakeTimeout 和 ResponseHeaderTimeout 必须设，防止单个慢请求拖垮整批

client := &http.Client{
    Transport: &http.Transport{
        MaxIdleConns:        300,
        MaxIdleConnsPerHost: 300,
        IdleConnTimeout:     60 * time.Second,
        TLSHandshakeTimeout: 10 * time.Second,
        ResponseHeaderTimeout: 15 * time.Second,
    },
    Timeout: 20 * time.Second,
}

并发控制不能只靠客户端——必须配合限流

即使客户端配置再优，上游服务扛不住照样失败。Go 标准库没内置限流器，但可用 golang.org/x/sync/semaphore 快速实现信号量控制：

• 每个请求前 sem.Acquire(ctx, 1)，完成后 sem.Release(1)
• sem 容量建议设为 50–200，具体看目标服务 SLA 和压测结果
• 别用 time.Sleep 或 rate.Limiter 替代——前者浪费 goroutine，后者不阻塞，可能瞬间打爆连接池

HTTP/2 和连接复用的实际影响

Go 1.6+ 默认启用 HTTP/2（只要服务端支持），它天然支持多路复用，单连接可并发处理多个请求。但要注意：

立即学习“go语言免费学习笔记（深入）”；

• 若目标服务禁用 HTTP/2（返回 http: server gave HTTP response to HTTPS client 类错误），需显式禁用：Transport.ForceAttemptHTTP2 = false
• HTTP/2 下 MaxIdleConnsPerHost 意义减弱，但 MaxConnsPerHost（Go 1.19+）才真正限制并发流数，旧版本需靠上层限流兜底
• 不要为“看起来更快”而关闭 Keep-Alive——HTTP/1.1 的复用收益在多数场景仍显著

真实压测中，多数性能拐点不在客户端配置，而在未做并发控制、TLS 握手阻塞、或 DNS 解析未缓存。这些比调 MaxIdleConns 更容易被忽略。