默认的 http.DefaultClient 在高并发下易出问题，因其底层 http.Transport 默认配置保守：MaxIdleConns=100、MaxIdleConnsPerHost=2、未启用 TLSSessionCache、超时未设，导致连接阻塞、DNS 卡顿、TLS 延迟飙升。
为什么默认的 http.DefaultClient 在高并发下容易出问题
它复用的底层 http.Transport 实例默认配置偏保守：最大空闲连接数只有 100，每个 host 最多 2 个空闲连接，TLS 握手不复用会话（TLSSessionCache 未启用），且没有设置合理的超时。这些在压测或突发流量下会直接表现为连接阻塞、DNS 解析卡住、TLS 握手延迟飙升。
-
MaxIdleConns和MaxIdleConnsPerHost必须显式调大，否则连接池很快耗尽，新请求排队等待空闲连接 - 务必设置
IdleConnTimeout和TLSHandshakeTimeout，避免僵死连接占资源 - 启用
ForceAttemptHTTP2（Go 1.6+ 默认开启）和TLSSessionCache可显著降低 HTTPS 建连开销 - DNS 缓存依赖系统 resolver，若需更细粒度控制（如自定义 TTL 或 fallback），得替换
Resolver
如何定制一个生产可用的 http.Client
不要复用 http.DefaultClient，也不要每次请求都新建 http.Client。应全局复用一个配置合理的实例，其核心是定制背后的 http.Transport。
client := &http.Client{
Transport: &http.Transport{
Proxy: http.ProxyFromEnvironment,
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
DualStack: true,
}).DialContext,
MaxIdleConns: 200,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 90 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
ExpectContinueTimeout: 1 * time.Second,
ForceAttemptHTTP2: true,
TLSClientConfig: &tls.Config{
ClientSessionCache: tls.NewLRUClien
tSessionCache(100),
},
},
Timeout: 10 * time.Second,
}
注意：Timeout 是整个请求生命周期上限，而 Transport 内部的各 timeout 控制建连、TLS、响应头读取等阶段；两者需协同，避免某一层无限等待拖垮整体。
http.RoundTripper 替换场景：需要重试、日志、熔断或指标采集
直接修改 Transport 配置不够灵活时，可包装 RoundTripper。比如加简单重试逻辑（仅对幂等方法）：
type RetryRoundTripper struct {
rt http.RoundTripper
}
func (r RetryRoundTripper) RoundTrip(req http.Request) (http.Response, error) {
var resp http.Response
var err error
for i := 0; i < 3; i++ {
resp, err = r.rt.RoundTrip(req)
if err == nil && resp.StatusCode < 500 {
return resp, nil
}
if i == 2 {
break
}
time.Sleep(time.Second * time.Duration(i+1))
}
return resp, err
}
client.Transport = &RetryRoundTripper{rt: client.Transport}
关键点：req.Body 是 io.ReadCloser，重试前必须能重放——标准库的 strings.NewReader 或 bytes.NewReader 构造的 body 可重放，但原始网络 body 不行；需提前用 httputil.DumpRequestOut 或手动缓存 body 字节。
容易被忽略的细节：DNS 缓存、HTTP/2 流量特征、Goroutine 泄漏
Go 的 net/http 不做 DNS 缓存，每次解析都走系统调用。高频请求下，getaddrinfo 成为瓶颈。解决方案不是自己写 DNS cache，而是用 net.Resolver 配合内存缓存（如 groupcache 或 freecache）封装一次。
- HTTP/2 下单连接多路复用，
MaxIdleConnsPerHost的意义变小，但MaxConnsPerHost（Go 1.19+ 引入）开始影响并发上限 - 使用
context.WithTimeout包裹请求，比只靠Client.Timeout更可控；尤其在链路中嵌套调用时，避免子请求继承父 context 的 deadline 漏洞 - 忘记关闭
Response.Body会导致底层连接无法归还连接池，长期运行后netstat -an | grep :443 | wc -l会持续上涨
连接池状态没法直接观测，但可通过 http.DefaultTransport.(*http.Transport).IdleConnMetrics()（Go 1.21+）或第三方包如 go-http-metrics 抓取实时指标。没升级到新版时，最简单的验证方式是压测前后执行 lsof -i :443 | wc -l 看 ESTABLISHED 连接数是否稳定。
