IdleConnTimeout控制空闲连接在池中等待复用的最大时长，非总连接时长；它与Timeout（整体请求时限）、ResponseHeaderTimeout（等待响应头时限）各司其职；若大于服务端IdleTimeout，将导致连接重置错误。
http.Transport.IdleConnTimeout 控制客户端空闲连接生命周期
客户端连接池中空闲连接的存活时间，由 idleconntimeout 决定。它不是“连接总时长”，而是“最后一次使用后、等待下一次复用的最大空闲时间”。一旦超时，连接会被 transport 主动关闭并从池中移除。
常见错误是把它和 Timeout（整个请求耗时上限）或 ResponseHeaderTimeout 混淆——这三个超时互不替代，各自守好自己的阶段：
-
Timeout：从client.Do()开始到响应体读完的总时限，超时会取消整个请求 -
ResponseHeaderTimeout：发出请求后，等待服务器返回状态行和响应头的最长时间 -
IdleConnTimeout：连接已归还给池、但一直没人再用它的“待岗时长”
若服务端 Keep-Alive timeout 设为 45s，而你把 IdleConnTimeout 设成 90s，那客户端保留的连接大概率会在下次复用前被服务端静默断开，导致下一次请求触发 net/http: HTTP/1.x transport connection broken 类错误。
MaxIdleConnsPerHost 默认值 2 是高频请求的性能瓶颈
Go 的 http.Transport 默认只允许每个 Host（如 api.example.com）最多缓存 2 个空闲连接。这意味着：哪怕你并发发起 100 个请求到同一域名，最多只有 2 个连接能被复用，其余请求仍会新建 TCP 连接——直接抵消连接复用收益。
典型表现是 netstat -an | grep :443 | wc -l 持续升高，同时观察到大量 TIME_WAIT 状态（虽然客户端侧通常不构成瓶颈，但数量突增说明复用失败）。修复方式很简单：
- 显式设置
MaxIdleConnsPerHost，例如50或100，不要依赖默认值 - 确保
MaxIdleConns≥MaxIdleConnsPerHost × 预期并发域名数，否则全局池会先满 - 避免在循环里 new
&http.Client{}，必须复用同一个 client 实例
服务端 IdleTimeout 与客户端 IdleConnTimeout 必须对齐
Go 服务端的 http.Server.IdleTimeout 和客户端的 IdleConnTimeout 是一对配合参数。它们共同决定“连接到底能闲多久”。不对齐会导致两种典型问题：
- 客户端
IdleConnTimeout> 服务端IdleTimeout：连接在服务端已被关闭，客户端却还试图复用，结果是read: connection reset by peer - 客户端
IdleConnTimeoutIdleTimeout：连接过早被客户端主动丢弃，浪费服务端 keep-alive 能力，增加建连开销
建议策略：先确认服务端配置（比如 Nginx 的 keepalive_timeout 或 Go http.Server.IdleTimeout），然后将客户端 IdleConnTimeout 设为该值的 80%～90%，留出网络抖动余量。例如服务端设了 60s，客户端就设 50 * time.Second。
resp.Body.Close() 不调用，IdleConnTimeout 就不会生效
这是最容易被忽略的逻辑前提：只有调用了 resp.Body.Close()，连接才真正归还给连接池，IdleConnTimeout 的倒计时才会开始。如果忘记关闭、或只读了部分 body 就丢弃，连接会一直被占用，既不超时也不复用。
更隐蔽的问题是：用 ioutil.ReadAll(resp.Body) 或 io.Copy(ioutil.Discard, resp.Body) 后没关；或者用 defer resp.Body.Close() 但在 error 分支提前 return 导致 defer 未执行。
安全写法是统一收口：
resp, err := client.Do(req)
if err != nil {
return err
}
defer resp.Body.Close() // 放在 err 检查之后，确保一定执行
body, err := io.ReadAll(resp.Body)
if err != nil {
return err
}
注意：HTTP/2 下复用逻辑不同，但 resp.Body.Close() 仍是必须的，否则流无法释放。
