go的http.client默认支持连接复用，但需正确配置transport参数并避免新建client、不关resp.body等误操作；否则会导致连接泄露、time_wait堆积和fd耗尽。
Go 的 http.Client 默认就支持 HTTP 连接复用，根本不用自己写连接池；真正要做的，是正确配置 http.Transport 并避免几个高频误操作。
为什么新建 http.Client 是性能陷阱
每次 &http.Client{} 都会生成一个独立的 http.Transport 实例，意味着：所有空闲连接彼此隔离、无法复用；大量 TIME_WAIT 连接堆积；文件描述符（FD）快速耗尽。尤其在 HTTP handler 里临时 new client，几秒内就能把系统打挂。
- 正确做法：全局复用一个
http.Client实例（比如包级变量或依赖注入单例） - 错误写法示例：
func handler(w http.ResponseWriter, r *http.Request) { client := &http.Client{}; client.Do(...) } - 若需不同超时/代理策略，应复用同一个
http.Transport，而非新建Client
MaxIdleConnsPerHost 设太小会导致请求卡死
这个参数控制「每个目标 host（如 api.example.com:443）最多缓存几个空闲连接」，不是并发上限，也不是活跃连接数上限。默认值仅 2，高并发调用单个下游服务时极易触发 net/http: request canceled (Client.Timeout exceeded while awaiting headers) 或大量重建连接。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 典型场景：稳定压测 60 QPS 打同一支付网关 → 建议设为
25–30 - 若同时调用 50+ 不同域名，
MaxIdleConns（全局总数）也得同步放大，否则某几个 host 把池子占满，其他请求就只能干等或新建连接 - 设太大（如 >100）反而有害：失效连接滞留更久，当下游 LB 切换 IP 后，旧连接可能还在池里持续失败
超时必须分层，Client.Timeout 只是兜底
Client.Timeout 是总超时，覆盖建连、重定向、读响应体全过程，但它不干预 DNS 解析、TLS 握手、响应头读取等中间阶段。只靠它，很容易出现 goroutine 泄漏或请求卡在 TLS 握手环节不动。
- 必须配
Transport级超时：DialTimeout（建议 3–5s）、TLSHandshakeTimeout（HTTPS 必设，≤5s）、ResponseHeaderTimeout（建议 10s） - 必须用
context.WithTimeout包裹每次请求：req, _ := http.NewRequestWithContext(ctx, ...)，这是唯一能中断 DNS 查询和重定向跳转的方式 -
IdleConnTimeout推荐 30–90s：太短（如 5s）导致刚缓存就过期，复用率归零；太长（如 5m）会让已断开的连接滞留池中
别忘了 resp.Body.Close()，否则连接永远回不去池子
哪怕你 Transport 配得再完美，只要没显式关闭 resp.Body，连接就不会被放回空闲池——它会被一直占用，直到 IdleConnTimeout 到期或程序退出。后果就是连接池逐渐枯竭，后续请求全走新建连接路径。
- 最简安全写法：
defer resp.Body.Close()放在client.Do()之后立即执行 - 如果要读响应体，务必先
io.Copy(ioutil.Discard, resp.Body)或完整读完再关，否则部分数据未读也会阻塞连接回收 - 注意：
http.DefaultClient的 Transport 无法定制，且和其他库（如 OpenTelemetry）共享，不推荐直接改它
真正难的不是参数本身，而是理解每个参数作用的边界：比如 MaxIdleConnsPerHost 只管“空闲”连接，不管活跃数；IdleConnTimeout 控制的是“躺平时间”，不是“寿命上限”。这些细节一旦混淆，调参就变成玄学。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
