Go http.Client 优化需合理设置连接池参数与分层超时：MaxIdleConns、MaxIdleConnsPerHost、IdleConnTimeout 控制复用，DialContext、TLSHandshake、ResponseHeader 及 Context 四层超时保障健壮性，且须复用单例 client。
Go 的 http.Client 默认已启用连接复用（即连接池），但若不显式配置，容易因默认行为导致资源耗尽、请求堆积或长时间卡死。优化核心在于两件事：合理设置连接池参数 + 严格控制超时。下面直接说关键点和怎么配。
连接池：控制最大连接数和空闲连接
默认的 http.DefaultTransport 允许无限复用连接，但每个 host 最多只保持 2 个空闲连接，且不限制总连接数——这在高并发调用下游服务时极易打满文件描述符或压垮对方。
建议显式构造 http.Transport 并限制：
- MaxIdleConns：整个 Transport 可保持的最大空闲连接总数（比如设为 100）
- MaxIdleConnsPerHost：每个 host（如 api.example.com）最多保持的空闲连接数（建议 50～100，避免单域名占满）
- IdleConnTimeout：空闲连接最长存活时间（推荐 30s，防止 NAT 超时断连）
-
ForceAttemptHTTP2：设为
true（Go 1.6+ 默认开启，确保复用 HTTP/2 连接）
超时控制：必须分层设置，不能只靠 context
仅用 context.WithTimeout 包裹 client.Do() 是不够的——它只控制“从发起请求到收到响应头”的总时间，无法中断 DNS 解析、TLS 握手、连接建立等前置阶段。
正确做法是四层超时全配：
- DialContext Timeout：控制建立 TCP 连接的最长时间（建议 5～10s）
- TLSHandshakeTimeout：TLS 握手超时（建议 5s）
- ResponseHeaderTimeout：从连接建立完成到收到响应头的时间（建议 5s，防后端卡在逻辑里）
- Context timeout（Do 时传入）：整体请求生命周期上限（建议略大于前三者之和，如 15s）
复用 client 实例，别每次 new
http.Client 是线程安全的，内部 transport 也支持并发。全局复用一个 client 实例即可，避免重复创建 transport 导致连接池失效、GC 压力增大。
错误写法：client := &http.Client{...} 放在函数内；
正确写法：定义包级变量或通过依赖注入传递单例 client。
可选增强：失败重试 + 熔断（非标准库，需额外库）
标准库不提供自动重试或熔断。如果下游不稳定，建议搭配 github.com/hashicorp/go-retryablehttp 或 golang.org/x/time/rate + sony/gobreaker 使用。注意：GET 请求可安全重试，POST/PUT 建议加幂等键，避免重复提交。
基本上就这些。连接池和超时不是“开了就行”，而是要根据你的 QPS、下游 SLA、网络环境来调——先按推荐值起步，再看监控（连接数、超时率、P99 延迟）逐步调优。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
