go 的 http.client 默认复用连接，但需正确配置 http.transport；若未显式设置 maxidleconns 和 maxidleconnsperhost，高并发下易因连接池过小导致 time_wait 爆满、qps 下降。
Go 的 http.Client 默认就复用连接，但得配对用 http.Transport
Go 的 HTTP 客户端默认不是“每次请求新建 TCP 连接”，而是靠底层 http.Transport 管理连接池。但很多人直接用 http.Get 或没配 Transport，结果压测时发现 TIME_WAIT 爆满、QPS 上不去——问题不在“要不要复用”，而在“有没有让复用生效”。
关键点：全局默认的 http.DefaultClient 虽带 Transport，但它的 MaxIdleConns 和 MaxIdleConnsPerHost 默认都是 100，小流量够用，高并发或调用多域名时很容易成为瓶颈。
-
MaxIdleConns控制整个客户端最多保持多少空闲连接（所有 host 加起来） -
MaxIdleConnsPerHost控制单个 host 最多保持多少空闲连接（比如 api.example.com 独占 100） - 如果只调大
MaxIdleConnsPerHost却忽略MaxIdleConns，后者会先掐断连接复用 -
IdleConnTimeout建议设为 30–90 秒，太短导致频繁重建，太长可能卡住异常连接
为什么用了自定义 http.Client 还是不复用？检查 Transport 是否被覆盖
常见错误：在中间件或工具函数里反复 new http.Client{}，却没传入复用型 Transport，或者误把 http.DefaultTransport 直接 cast 后修改——它是个包级变量，改了会影响其他模块，而且不是线程安全的。
正确做法是显式构造独立 http.Transport 实例，再注入 Client：
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
tr := &http.Transport{
MaxIdleConns: 200,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 60 * time.Second,
}
client := &http.Client{Transport: tr}
- 别用
http.DefaultTransport.(*http.Transport)强转修改，这是危险操作 - 每个业务逻辑应使用自己的
Client实例，避免共享Transport导致配置冲突 - 如果用了
RoundTripper包装器（如加日志、重试），确保内部 transport 是可复用的，且没屏蔽CloseIdleConnections
http.Transport 复用失效的典型现象和排查方式
连接不复用最直接的表现不是报错，而是系统层面可观测到大量 TIME_WAIT、ESTABLISHED 数量波动剧烈，或 pprof 查 net/http 阻塞在 dial 上。
- 现象：
netstat -an | grep :443 | wc -l持续上涨，且多数状态为TIME_WAIT - 现象：pprof 的
/debug/pprof/goroutine?debug=1显示大量net/http.(*Transport).dialConngoroutine 卡住 - 检查点：确认请求 URL 的 scheme（
httpvshttps）、host（含端口）、proxy 设置是否一致——哪怕端口不同（api.example.com:8080vsapi.example.com:443）也会视为不同 host，不共享连接池 - 检查点：确认没在请求中设置
Header.Set("Connection", "close")，这会强制关闭连接
高并发下要注意 http.Transport 的 FD 和内存开销
调大连接池不是无代价的。每个空闲连接都占一个文件描述符（FD），同时保留在内存里维护 TLS session、buffer 等状态。Linux 默认每进程 1024 FD，跑满会直接 panic: “too many open files”。
- 用
ulimit -n查当前限制，生产环境建议设为 65536 或更高 -
MaxIdleConnsPerHost不建议盲目设到 1000+，除非你确定后端能扛住且连接真的活跃；更稳妥的是结合Response.Body.Close()是否被调用——漏关会导致连接无法归还池子 - TLS 握手耗时高时，可开启
TLSDialContext缓存或复用*tls.Config，避免每次新建 config 实例 - 如果调用目标是云服务（如 AWS API），注意它们本身有连接数/请求频次限制，池子过大反而触发限流
连接复用真正难的不是写几行配置，而是理解 transport 的生命周期、host 分组规则、以及它和操作系统资源的耦合关系。一个没关的 Body、一次错写的 Connection: close、或一个共享的 default transport，都可能让所有优化归零。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
