go http.client 默认连接池因 maxidleconnsperhost=2 过小，高并发下复用率低、频繁建连握手，导致端口耗尽和超时；需合理配置 maxidleconnsperhost、maxconnsperhost、idleconntimeout 及 dialcontext 参数。
Go 的 http.Client 默认就带连接池，不用“做”，只需要正确配置 http.Transport —— 配错反而比不用还慢。
为什么默认连接池在高并发下会卡住或超时
Go 标准库的 DefaultTransport 确实启用了 Keep-Alive 和连接复用，但它的默认参数极其保守：MaxIdleConnsPerHost = 2，IdleConnTimeout = 30s。这意味着：单个域名最多只缓存 2 个空闲连接，第 3 个请求就得新建 TCP 连接；而频繁建连 + TLS 握手，在微服务调用或批量爬虫场景下，立刻出现 dial tcp: too many open files 或大量 context deadline exceeded。
- 现象：压测时 QPS 上不去，
netstat -an | grep :443 | wc -l显示数百个TIME_WAIT，CPU 不高但延迟飙升 - 根本原因：连接池太小 → 复用率低 → 频繁握手 → 系统端口/文件描述符耗尽
- 关键参数不是“开不开”，而是“设多大”：重点调
MaxIdleConnsPerHost、MaxConnsPerHost、IdleConnTimeout
怎么配 transport 才算合理
没有全局最优值，得看你的下游服务能力和自身并发模型。比如你用一个 client 并发调 50 次 https://api.example.com，那 MaxIdleConnsPerHost 设 2 就是自缚手脚。
-
MaxIdleConnsPerHost：建议设为「目标并发请求数 ÷ 2」左右（如 50 并发 → 设 20～25），它控制每个域名能缓存几个空闲连接 -
MaxConnsPerHost：必须 ≥MaxIdleConnsPerHost，建议设为前者的 1.2～1.5 倍（防突发），它限制对单个 host 的总连接数（含活跃中） -
IdleConnTimeout：设 30～90 秒，太短导致刚缓存就销毁，太长可能占着连接不放；注意它和下游服务的 keep-alive timeout 要匹配（常见 Nginx 默认 75s） - 别漏掉
DialContext：加Timeout和KeepAlive，否则 DNS 解析或连接建立阶段卡死会拖垮整个池
transport := &http.Transport{
DialContext: (&net.Dialer{
Timeout: 5 * time.Second,
KeepAlive: 30 * time.Second,
}).DialContext,
MaxIdleConns: 100,
MaxIdleConnsPerHost: 25,
MaxConnsPerHost: 30,
IdleConnTimeout: 60 * time.Second,
TLSHandshakeTimeout: 5 * time.Second,
}
client := &http.Client{Transport: transport, Timeout: 10 * time.Second}
哪些情况要禁用连接池
极少需要禁用，但真有：比如你每次请求都换代理 IP、或下游服务明确拒绝复用（返回 Connection: close）、或你用的是短生命周期的一次性 client（如 CLI 工具里发一两个请求就退出）。
- 禁用方式只有两种：
DisableKeepAlives = true，或把MaxIdleConnsPerHost设为 ≤ 0 - 错误做法：只设
MaxIdleConnsPerHost = 1—— 这不会禁用，只是让池“几乎没用”，还保留握手开销 - 注意副作用：禁用后每个请求都是全新 TCP 连接，
TIME_WAIT会暴增，本地端口可能快速耗尽（尤其在 Linux 上net.ipv4.ip_local_port_range默认仅 32768–65535）
怎么验证连接池真的在工作
别猜，用 netstat 和 client 自带的统计看。
- 运行时执行：
netstat -an | grep ':443' | grep ESTABLISHED | wc -l，连续请求多次，如果数量稳定在 20～25（接近你设的MaxIdleConnsPerHost），说明复用成功 - 代码里打印 transport 统计：
transport.IdleConnStats()（需 Go 1.22+），或更通用的：访问http.DefaultTransport.(*http.Transport).IdleConnStats()（注意类型断言） - 容易忽略的坑：多个
http.Client实例各自维护独立连接池 —— 全局复用一个 client 实例，别在 handler 里 new client
最常被跳过的细节是：IdleConnTimeout 和下游服务的 keep-alive 超时不一致，导致连接被对方先关闭，而你的 client 还以为它可用，下次复用时直接报 read: connection reset by peer —— 这种错误日志看起来像网络问题，其实是池配置和对方协议没对齐。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
