默认 http.DefaultClient 在高并发下卡住，因其 MaxIdleConns 和 MaxIdleConnsPerHost 默认仅100，IdleConnTimeout 为30秒，多 host 高频请求易耗尽连接池，导致等待或建连延迟；应全局复用定制 transport 的 client 实例，并合理调优参数。
为什么默认的 http.DefaultClient 在高并发下会卡住
Go 的 http.DefaultClient 底层复用 http.Transport，但它的默认配置是为“偶尔发几个请求”设计的：MaxIdleConns 和 MaxIdleConnsPerHost 都是 100，IdleConnTimeout 是 30 秒。在每秒数百请求、多 host 场景下，连接池很快耗尽，后续请求被迫等待空闲连接或新建连接，造成延迟毛刺甚至超时。
-
MaxIdleConns控制整个客户端能缓存多少空闲连接（含所有 host），设太小会导致频繁建连；设太大可能耗尽文件描述符（尤其容器环境） -
MaxIdleConnsPerHost是 per-host 限制，必须显式调大，否则即使全局够用，单个 API 域名也会被限死 -
IdleConnTimeout过长会让失效连接滞留，过短则失去复用价值；建议 30–90 秒，视后端稳定性调整
如何安全地复用 http.Client 实例
每次请求都 new(http.Client) 是常见反模式：每个 client 持有独立 transport，连接池不共享，还可能泄漏 goroutine 和 fd。正确做法是全局复用一个 client 实例（或按业务域分组复用），并在初始化时定制 transport。
- client 实例是并发安全的，可放心在多个 goroutine 中调用
Do() - 不要在 handler 里临时创建 client；如果需不同 timeout 或 proxy，应新建 transport 并绑定到新 client，而非反复 new client
- 若用
context.WithTimeout控制单次请求，它只影响本次Do()，不影响 transport 复用逻辑
var httpClient = &http.Client{
Transport: &http.Transport{
MaxIdleConns: 200,
MaxIdleConnsPerHost: 200,
IdleConnTimeout: 60 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
},
Timeout: 10 * time.Second,
}
http.Transport 关键参数对吞吐的实际影响
吞吐瓶颈常不在 CPU 或网络带宽，而在 transport 层的连接管理与 TLS 握手开销。几个参数改动能带来明显提升：
aperture: the L402 aware reverse proxy
下载
安装并运行 Aperture（Lightning Labs 的 L402 闪电反向代理），用于创建 L402 付费墙、配置付费 API 端点、为其他代理托管付费内容或测试 L402 认证流程。
-
TLSHandshakeTimeout：默认 10 秒，高并发下若某后端 TLS 响应慢，会拖垮整个连接池；设为 3–5 秒更合理 -
ResponseHeaderTimeout：从发送完 request 到收到 header 的最大等待时间，防后端卡在写 body；设为略大于预期 header 返回时间（如 3 秒） -
ExpectContinueTimeout：仅当 request body >1MB 且 header 含Expect: 100-continue才触发，默认 1 秒；一般可忽略，除非你主动发大 body - 禁用 HTTP/2？不推荐。Go 1.6+ 默认启用，它通过多路复用降低连接数和握手次数；除非后端明确不支持，否则保留
如何验证优化是否生效
光看 QPS 提升不够，要确认底层连接行为是否符合预期。关键观测点：
立即学习“go语言免费学习笔记（深入）”；
- 用
net/http/pprof查看/debug/pprof/goroutine?debug=1，确认没有大量阻塞在transport.dialConn或transport.getIdleConn - 检查
http.Transport的指标（需自行埋点）：重点关注IdleConn数量是否稳定、CloseIdleConns()调用后是否真释放了连接 - 用
lsof -p <pid> | grep "TCP" | wc -l监控 fd 数，避免因MaxIdleConns过大导致 “too many open files” - 对比优化前后
curl -w "@format.txt" -o /dev/null -s http://x中的time_connect和time_starttransfer，下降明显说明连接复用起效
真正难的是平衡：调太高怕压垮服务端或耗尽本地资源，调太低又浪费复用能力。实际值得根据压测结果微调，而不是套用文档默认值。
