默认 http.Client 在高并发下易变慢或超时，因其 DefaultTransport 的 MaxIdleConns=100、MaxIdleConnsPerHost=2 导致连接争用与频繁建连；应自定义 Client 并调优 Transport 参数。
为什么默认的 http.Client 在高并发下容易变慢甚至超时
Go 默认的 http.Client 用的是共享的 http.DefaultTransport，而它底层的 http.Transport 默认只允许最多 100 个空闲连接（MaxIdleConns: 100），对同一 host 最多 2 个空闲连接（MaxIdleConnsPerHost: 2）。这意味着：当并发请求猛增时，大量请求会排队等复用连接，或反复建连/断连，导致延迟飙升、TLS 握手开销大、甚至触发 context deadline exceeded。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 显式构造自定义
http.Client，不要依赖http.DefaultClient - 把
MaxIdleConns和MaxIdleConnsPerHost设为足够大的值（如 1000），避免连接池过早“挤满” - 设置
IdleConnTimeout（推荐 30s）和TLSHandshakeTimeout（如 10s），防止空闲连接长期占位或 TLS 卡死 - 如果调用的是固定后端（比如内部微服务），开启
ForceAttemptHTTP2: true（Go 1.6+ 默认开启，但显式声明更稳妥）
http.Transport 的 ResponseHeaderTimeout 和 ExpectContinueTimeout 怎么设才不拖慢请求
这两个超时参数常被忽略，但它们直接影响“发完请求头之后”的等待行为。比如 ResponseHeaderTimeout 控制从写完 request header 到收到 response header 的最大时间；若后端处理慢（如数据库查询卡住），这个 timeout 一到就直接失败，比等完整响应更早止损。而 ExpectContinueTimeout 只在请求头含 Expect: 100-continue 时生效——大多数 HTTP client 不发这个头，所以通常可设为 1s 或直接禁用（设为 0）。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
-
ResponseHeaderTimeout建议设为略大于后端 P95 处理时长（如 2–5s），避免 header 阶段无限等待 -
ExpectContinueTimeout设为0，除非你明确需要 100-continue 流程（例如上传大文件前确认服务端接收意愿） - 注意：这些 timeout 是独立于
http.Client.Timeout的，后者控制整个请求生命周期（包括 DNS、拨号、TLS、header、body），别混淆
如何安全复用 http.Client 实例而不引发 goroutine 泄漏
http.Client 是协程安全的，可以全局复用——但前提是 Transport 没被意外关闭，且没在每次请求里新建 client。常见泄漏场景是：在 handler 或循环中反复 &http.Client{...}，导致每个 client 持有独立 transport，而 transport 内部的 idle connection goroutine 不会自动退出，积少成多就吃光资源。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 在包初始化或应用启动时创建单个 client 实例（如
var httpClient = &http.Client{...}），所有地方复用它 - 不要在函数内 new client，尤其别在 HTTP handler 里做这件事
- 如果真要按场景隔离 client（如区分 internal / external 调用），也应使用 sync.Once 或 init 函数初始化，而非运行时动态构造
- 必要时可调用
transport.CloseIdleConnections()主动清理（比如配置热更新后），但日常无需频繁调用
要不要用 WithContext？哪些 timeout 必须靠 context 控制
http.Client.Do(req) 本身不感知 context，但 http.NewRequestWithContext 创建的请求携带 context，client 会在读写 body、重定向、或等待 response body 时检查 context 是否已 cancel 或 timeout。关键点在于：context timeout 是唯一能可靠中断「正在读 response body」的机制——transport 层级的 timeout 对 body 读取无效。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 总是用
http.NewRequestWithContext构造请求，哪怕只是传context.Background() - 对外部不可信服务（如第三方 API），必须设 context timeout（如
context.WithTimeout(ctx, 3*time.Second)），否则慢响应可能 hang 住整个 goroutine - 对内部服务，可放宽，但建议至少设一个兜底 timeout（如 10s），防止链路某环意外卡死
- 别以为设置了
Client.Timeout就万事大吉——它不覆盖 body 读取阶段，该卡还是卡
api.example.com 和 API.EXAMPLE.COM 被视为两个不同 host，各自维护连接池。DNS 轮询、服务网格注入的端口、甚至 URL 拼接时的大小写处理，都可能悄悄破坏复用效果。 
