resp.Body.Close() 必须调用，否则连接无法归还 idle pool，导致 TIME_WAIT 暴涨、too many open files 错误；漏掉它，即使只读 StatusCode，连接也卡在“已用未还”状态。
为什么 resp.Body.Close() 不是“关不关都行”
它直接决定连接能不能回到 idle pool。漏掉这一步，哪怕只读了 resp.StatusCode，连接就卡在“已用未还”状态，后续请求只能新建连接——netstat -an | grep TIME_WAIT 会暴涨，too many open files 报错也会准时出现。
常见错误写法：
-
resp, _ := client.Get(url); data, _ := io.ReadAll(resp.Body)—— 没调resp.Body.Close() -
defer resp.Body.Close()放在函数开头，但中间 panic 或提前 return，导致没执行
更稳妥的做法是：读完立刻关，或用带 recover 的 defer：
defer func() {
if resp != nil && resp.Body != nil {
_ = resp.Body.Close()
}
}()
MaxIdleConnsPerHost 设太小会卡住单个域名
这个参数不是“全局池大小”，而是“每个 host 最多缓存多少空闲连接”。默认值 100 看似够用，但压测时如果所有请求都打向 api.example.com，而你并发 200，后 100 个请求就会排队等连接释放，QPS 上不去。
关键点：
- 它和
MaxIdleConns是两个独立限制，建议设为相同值（比如 300），避免其中一个先触顶 - HTTP/2 下该参数失效（协议层自动复用），但 HTTP/1.1 场景下它是瓶颈点
- 如果混用大小写 host（如
API.EXAMPLE.COM和api.example.com），会被视为两个 host，各自占用配额
IdleConnTimeout 必须比服务端 keepalive_timeout 短
客户端空闲连接保活时间如果比服务端长，连接会在归还进池子后，被服务端先关闭——下次复用时发现是死连接，得重连，等于白配。
Nginx 默认 keepalive_timeout 是 75s，所以客户端 IdleConnTimeout 设成 60 * time.Second 更安全；Apache 若设了 KeepAliveTimeout 30，那客户端就得设成 25s 左右。
别依赖默认值（30s），尤其当服务端配置未知时，主动查或保守设低一点。
JSON 解析后 body 可能还没读完
json.NewDecoder(resp.Body).Decode(&v) 成功返回 ≠ resp.Body 已读到 EOF。它只消费构成一个 JSON 值所需的字节，后面可能还有换行、空格、甚至第二个 JSON 对象（如服务端流式返回多个对象）。
残留字节会让连接无法复用。正确做法：
- 调用
decoder.More()判断是否还有下一个 JSON 值 - 若有，用
io.Copy(io.Discard, resp.Body)清空剩余内容 - 若确定服务端只返回单个 JSON，也建议加一层兜底：
_, _ = io.Copy(io.Discard, resp.Body)
这步容易被忽略，因为错误不报在 decode，而是在后续请求的连接耗尽上慢慢暴露。
