应全局复用 http.client 实例，因其内部 transport 持有连接池；每次 new 会导致 tcp/tls 重复握手、端口耗尽及 time_wait 堆积，引发 dns 解析失败或 too many open files 错误。
为什么不能每次请求都 new http.Client()
因为 http.Client 内部持有连接池（http.Transport），每次新建会丢弃已有连接，导致 TCP 握手、TLS 协商重复发生，还可能快速耗尽本地端口（TIME_WAIT 堆积）。压测时常见 dial tcp: lookup xxx: no such host 或 too many open files 就是这个原因。
实操建议：
- 全局复用一个
http.Client实例，比如定义为包级变量或通过依赖注入传入 - 不要在 handler 里
&http.Client{}，哪怕只用一次 - 如果需要定制行为（如超时、代理），改
http.DefaultClient的 Transport 字段不安全，应新建 client 并复用它
如何安全配置复用的 http.Client
默认的 http.DefaultClient 虽然可复用，但超时是 0（无限等待），且 Transport 默认参数对高并发不友好。直接改 http.DefaultClient 会影响其他库（比如第三方 SDK 也用它）。
实操建议：
- 显式创建 client：
client := &http.Client{Timeout: 10 * time.Second} - 自定义 Transport 时，务必设置
MaxIdleConns和MaxIdleConnsPerHost，否则连接池实际未生效；例如设为 100 和 50 - 启用 Keep-Alive：Transport 默认已开，但需确保服务端也支持；若遇到
connection reset by peer，可能是后端过早关连接，这时要调小IdleConnTimeout
什么时候真需要多个 http.Client？
不是所有场景都该共用一个 client。典型例外是：不同目标域名有完全隔离的超时/重试/证书策略，或需独立的连接池控制（比如一个走内网直连，一个走 HTTP 代理）。
实操建议：
- 按「用途」而非「域名」分 client：比如
metricsClient、authClient，每个用途一个实例 - 避免按 URL 动态 new client；更不要在循环里 new
- 如果只是 Header 不同（如 Authorization），用
req.Header.Set()即可，无需新 client
复用 client 时容易被忽略的坑
最隐蔽的问题不是连接池，而是 client 复用后，其内部 Transport 的 Proxy、TLSClientConfig 等字段一旦设置就固定了，后续无法动态切换——但很多人误以为“每次 request 都能独立配置”。
实操建议：
- Body 没关闭会导致连接无法复用：
resp.Body.Close()必须执行，哪怕只读resp.StatusCode - 自定义
RoundTripper时，别忘了透传req.Context()，否则超时和 cancel 会失效 - 测试中用
httptest.Server时，client 可复用，但记得在 test 结束时调server.Close()，否则下次 test 可能端口冲突
真正麻烦的从来不是“怎么写”，而是“哪些状态被隐式共享了”。比如 Transport 的 IdleConnTimeout 改了，所有用它的 client 都受影响——这点在微服务间混用 client 时特别容易出问题。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
