默认 http.DefaultClient 在中高并发下不可用，因连接池参数过小、超时不分层、复用率低且易被污染；MaxIdleConnsPerHost=2 是最常踩坑点，导致高 QPS 下连接复用率极低、TIME_WAIT 暴涨、频繁新建连接。
默认的 http.DefaultClient 在中高并发下基本不可用，不是“能跑”，而是“会悄悄拖垮服务”——连接池参数过小、超时不分层、复用率低、还容易被第三方库污染。
为什么 MaxIdleConnsPerHost=2 是最常踩的坑
这个值控制「每个域名（含端口）最多缓存几个空闲连接」，不是并发上限，也不是活跃连接数。默认 2 意味着：哪怕你 QPS 是 50，只要请求都打向 https://api.pay.example.com，绝大多数请求根本等不到复用连接，只能排队或新建连接。
- 现象：大量
net/http: request canceled (Client.Timeout exceeded while awaiting headers)，TIME_WAIT连接暴涨，strace看到频繁connect()系统调用 - 误判：以为是 DNS 或 TLS 问题，实际是连接刚用完就被关，下次还得重连
- 调法：对固定后端（如内部微服务、支付网关），设为预期并发的 1/3～1/2；例如稳定 60 QPS，可设
MaxIdleConnsPerHost: 25 - 注意：如果同时调 50+ 不同域名，
MaxIdleConns（全局总数）必须同步放大，否则某几个 host 把池子占满，别的 host 就拿不到连接
IdleConnTimeout 设太短或太长都会让连接池失效
它决定空闲连接在池里躺多久才被关掉。默认 30 秒（Go 1.19+ 后是 90 秒），但很多服务端 LB（Nginx/ALB/Envoy）keepalive timeout 是 60～75 秒，客户端设得比它还长，就会复用到已被服务端 RST 的连接。
- 太短（如 5s）：连接刚缓存就过期，复用率为零，全是短连接
- 太长（如 5m）：下游服务重启或 LB 切 IP 后，旧连接卡在池里继续失败，错误日志里反复出现
read: connection reset by peer - 推荐值：查清下游所有网关的
keepalive_timeout，取最小值减去 10 秒；常见设为60 * time.Second或90 * time.Second - 配套动作：必须和
Dialer.KeepAlive对齐，比如设KeepAlive: 30 * time.Second，避免中间设备主动断连
别碰 http.DefaultClient，也别每次请求都 &http.Client{}
http.DefaultClient 是全局单例，底层共享 http.DefaultTransport。任何包（比如 cloud.google.com/go 或 go.opentelemetry.io）修改它的 Transport，都会影响你的请求。
- 高频误操作：在 handler 里写
client := &http.Client{Transport: myTransport}—— 每次请求新建 client，每个 client 持有独立 transport，idle connection goroutine 不退出，内存和 fd 持续上涨 - 正确做法：定义一个包级变量或通过依赖注入传入单个
*http.Client实例，并确保Transport在初始化时完整配置，之后不再修改 - 关键检查点：确认没 anywhere 调用
http.DefaultTransport.(*http.Transport).CloseIdleConnections()，这会干掉所有其他模块正在用的连接 - Body 不关 = 连接不进 idle 状态：
resp.Body.Close()必须执行，否则连接永远不会被放回池中
Client.Timeout 和 Transport 超时是两套系统
http.Client.Timeout 是总生命周期超时，覆盖 DNS、拨号、TLS、写请求头、读响应头、读响应体全过程。但它对连接池内部行为完全无感——比如连接正卡在 TLS 握手，Client.Timeout 不会中断它。
- 真正影响连接复用效率的是
Transport的分层超时：DialTimeout（或DialContext）、TLSHandshakeTimeout、ResponseHeaderTimeout -
ResponseHeaderTimeout建议设为后端 P95 处理时长（如 2–5s），比等完整响应更早止损 -
ExpectContinueTimeout大多数场景不用，设为0即可；除非你明确发Expect: 100-continue头 - 漏配任意一个，都可能让连接池“看着有连接，实际全卡死”
真正难的不是记住参数名，而是在压测时观察 http.DefaultTransport.IdleConnMetrics（Go 1.19+）或自己打日志看 idle 连接数变化；还有就是搞清下游所有中间件的 keepalive 配置——这些细节不落地，再大的 MaxIdleConns 也只是数字游戏。
