HTTP客户端需协同配置Timeout、IdleConnTimeout和KeepAlive：Timeout设为略大于业务最大延迟（如10s），IdleConnTimeout设30–90秒，KeepAlive设30秒以加快异常断连清理；必须同时设置MaxIdleConns（如50）和MaxIdleConnsPerHost以防连接池失控。
HTTP 客户端的 Timeout、IdleConnTimeout 和 KeepAlive 怎么设才不泄漏连接
Go 的 http.Client 默认不设超时，长时间无响应或服务端卡住时，连接会一直挂起，最终耗尽文件描述符。关键不是“要不要设”，而是三个超时参数必须协同配置：Timeout 控制单次请求总耗时上限；IdleConnTimeout 控制空闲连接在连接池中保留多久；KeepAlive 控制 TCP 层是否发保活探测包（影响连接异常断开后的清理速度）。
常见错误是只设 Timeout，却忽略 IdleConnTimeout —— 这会导致连接池里的空闲连接永不释放，尤其在 QPS 低但服务长期运行的场景下，netstat -an | grep :443 | wc -l 会持续上涨。
-
Timeout建议设为略大于业务最大容忍延迟（如 10s），它覆盖 DNS 解析、建立连接、TLS 握手、发送请求、读取响应全过程 -
IdleConnTimeout推荐设为 30–90 秒，太短会频繁重建连接，太长则资源滞留；注意它只对复用的连接生效，新连接由Timeout管控 -
KeepAlive设为 30 秒可加快探测对端崩溃（如服务进程被 kill -9），避免客户端还傻等 FIN 包；但某些内网 LB 会丢弃保活包，此时可设为 0 关闭
使用 http.Transport 自定义连接池时，MaxIdleConns 和 MaxIdleConnsPerHost 必须显式限制
默认情况下，Go 的连接池不限制空闲连接数，MaxIdleConns 是全局上限，MaxIdleConnsPerHost 是每个域名/端口对的上限。不设它们，哪怕设置了 IdleConnTimeout，连接池仍可能在超时前就堆积大量空闲连接。
典型误配是只设 MaxIdleConnsPerHost = 10 却漏掉 MaxIdleConns —— 当你调用 20 个不同域名的 API 时，连接池最多可持有 20 × 10 = 200 个空闲连接，远超系统 ulimit -n 限制。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
MaxIdleConns应设为一个保守值，例如 50 或 100，作为整个客户端的硬性连接数天花板 -
MaxIdleConnsPerHost通常设为MaxIdleConns / 期望并发调用的 host 数量，若主要调一个后端，可直接设为与MaxIdleConns相同 - 如果明确不需要连接复用（如极低频调用），可设
MaxIdleConns = 0，此时每次请求都新建连接，也无需关心IdleConnTimeout
服务端 http.Server 的 ReadTimeout、WriteTimeout 和 IdleTimeout 配置逻辑与客户端不同
服务端的超时不是为了“释放自己资源”，而是防止恶意客户端占用连接。其中 ReadTimeout 从 Accept 连接开始计时，到读完全部请求头为止；WriteTimeout 从响应写入开始计时，到写完响应体结束；而 IdleTimeout（Go 1.8+）才是控制“连接建立后、未收请求或响应期间”的空闲等待时间，这才是对应客户端 IdleConnTimeout 的反向约束。
常见坑是把 ReadTimeout 设得太短（如 5s），导致大文件上传或慢速客户端直接被中断；或者没设 IdleTimeout，让僵尸连接长期占着 goroutine 和 fd。
- 生产环境建议设
IdleTimeout = 60 * time.Second，比客户端IdleConnTimeout略长一点，避免客户端刚准备复用连接，服务端已关闭它 -
ReadTimeout和WriteTimeout应按接口语义设置：上传接口可设为 300s，普通 JSON API 用 30s 足够 - 不要依赖
ReadTimeout来防慢速攻击，它无法覆盖 TLS 握手阶段；真正防攻击需配合反向代理层（如 nginx 的client_header_timeout）
验证连接是否真的被释放：别只看 netstat，要查 http.DefaultClient.Transport 的指标
光看系统级连接数容易误判——比如连接已关闭但 TIME_WAIT 状态还在，或连接池里有空闲连接但尚未触发超时。更准的方式是观测 Go 运行时暴露的连接池状态。
可以通过访问 http.DefaultClient.Transport（或自定义 client 的 transport）的字段来 debug，但注意这些字段是非线程安全的，仅用于诊断。生产环境推荐用 Prometheus + go_http_client_* 指标。
- 检查
transport.IdleConnStats()（Go 1.21+）返回的IdleConnCount和IdleConnClosed计数器，确认空闲连接是否随时间下降 - 用
lsof -p $(pidof your-go-binary) | grep "TCP.*ESTABLISHED" | wc -l对比重启前后数量，比netstat更精准 - 如果发现连接数稳定在某个值不再增长，但又远高于并发请求数，大概率是
MaxIdleConnsPerHost和IdleConnTimeout不匹配，比如前者为 100、后者为 5 分钟，而实际每分钟只发 1 个请求，连接就永远积压
配置错一个参数可能让服务在流量低谷时悄无声息地吃光文件描述符，而问题往往在上线几天后才爆发。最易被跳过的其实是 MaxIdleConns 的全局限制和 IdleTimeout 与客户端的时序对齐。
