go的http.client默认自带连接池，无需手动实现；关键在合理配置maxidleconnsperhost（默认仅2，易致频繁建连）、idleconntimeout（推荐30–90s）及务必调用resp.body.close()以确保连接归还池中。
Go 的 http.Client 本身不需“实现”连接池——它默认就带，关键是怎么不让它失效、怎么配得准、怎么用得稳。
为什么改了 MaxIdleConnsPerHost 还是频繁建连
默认值 MaxIdleConnsPerHost = 2 是最大陷阱。哪怕你只调一个域名（如 api.pay.example.com），每秒 30+ 请求时，两个空闲连接根本不够轮转，新请求只能排队或新建连接，导致 TIME_WAIT 堆积、dial tcp: lookup xxx: no such host 批量出现。
- 先确认是否真在复用：打印
http.DefaultClient.Transport.IdleConnMetrics（Go 1.19+）或用netstat -an | grep :443 | grep TIME_WAIT | wc -l观察连接状态 - 只调少数几个后端时，设
MaxIdleConnsPerHost = 50~100，MaxIdleConns = MaxIdleConnsPerHost × 2~3 - 若下游有几十个不同子域名（如第三方 API 聚合），优先保
MaxIdleConnsPerHost = 10~20，再放大MaxIdleConns，避免单个 host 吃光全局池 - 别漏掉
IdleConnTimeout：设太短（如5s）会让刚建好的连接立刻被关；设太长（如5m）可能卡在 NAT 或 LB 断连后的僵死状态，推荐30~90s
Response.Body.Close() 不调，连接池就等于没开
这是最隐蔽、最高频的连接池失效原因。只要没关响应体，底层 TCP 连接就一直被持有，无法归还给池子，MaxIdleConns 再大也白搭。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
resp, _ := client.Get(url); data, _ := io.ReadAll(resp.Body)—— 忘了resp.Body.Close() - 正确写法：必须在读完后立刻关，推荐
defer resp.Body.Close()，但注意 panic 或 context cancel 可能跳过 defer；更稳妥的是读完即关，不依赖 defer - 哪怕只取
resp.StatusCode，也要关：HTTP/1.1 下不关 body，服务端可能不释放连接；HTTP/2 下不关，流（stream）资源无法回收
HTTP/2 下 MaxIdleConnsPerHost 失效，该看什么
HTTP/2 启用后，连接复用由协议层控制，单个 TCP 连接可并发多路请求，MaxIdleConnsPerHost 不再生效。此时真正影响复用效果的是：
-
MaxConnsPerHost：限制每个 host 最大并发连接数（不是空闲连接），设太小会强制建新连接，推荐30~100 -
MaxConcurrentStreams：单个 HTTP/2 连接上允许的最大并发流数，默认250，一般不用调；但若下游服务限制低（如某些网关设为100），需同步下调 - 必须用
https://：HTTP/2 over TLS 是强制的，http://永远不会升级 - 服务端 ALPN 协商失败、证书不可信、或
Transport.ForceAttemptHTTP2 = true（已废弃）都可能导致降级回 HTTP/1.1，间接让连接池配置失效
连接池参数没有银弹，MaxIdleConnsPerHost 和 IdleConnTimeout 必须跟下游服务的 keepalive 配置对齐，差 5 秒都可能让连接在复用时突然断开。最稳妥的做法是：先查清 Nginx/Envoy/ALB 的 keepalive_timeout，取最小值减去 10 秒，作为你的 Dialer.KeepAlive 和 IdleConnTimeout 的上限。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
