根本原因是MaxIdleConnsPerHost默认为2导致连接无法复用，且resp.Body未读完就Close破坏复用逻辑；必须同步调大MaxIdleConnsPerHost、MaxConnsPerHost，并确保完整消费响应体。
Go HTTP 客户端默认配置在高并发场景下必然积累大量 TIME_WAIT，根本原因不是“用了长连接”，而是连接池没配对、响应体没读完、复用逻辑被破坏。
MaxIdleConnsPerHost 设置过小导致连接反复新建
Go 的 http.Transport 默认 MaxIdleConnsPerHost = 2，意味着每个目标 host（比如 influxdb.example.com:8086）最多只缓存 2 个空闲连接。当并发请求远超此数（如每秒 5000 次），绝大多数请求无法复用连接，只能新建 —— 每次新建 + 主动关闭就触发一次 TIME_WAIT。
- 若目标是单个后端（如 InfluxDB、自建 API），建议设为
MaxIdleConnsPerHost = 100或更高，与预期峰值 QPS 匹配 - 必须同步设置
MaxConnsPerHost≥MaxIdleConnsPerHost，否则连接池会阻塞等待，反而加剧超时 - 避免
MaxConnsPerHost远大于MaxIdleConnsPerHost：前者管“上限”，后者管“常驻”，失配会导致连接建了不用、立刻销毁
resp.Body 未读完就调用 Close() 破坏连接复用
Go 的 http.Transport 复用连接的前提是：完整消费响应体。如果只调 resp.Body.Close() 而不读取或丢弃 body，transport 会认为连接可能还残留未读数据，拒绝复用，强制关闭 —— 这是 TIME_WAIT 激增的隐蔽主因。
- 正确做法是：无论是否需要 body 内容，都必须显式处理它，例如
io.Copy(ioutil.Discard, resp.Body)（Go 1.19+ 改用io.Copy(io.Discard, resp.Body)） - 若需解析 JSON，用
json.NewDecoder(resp.Body).Decode(&v)，它内部会读完流；但若 decode 失败，仍要手动调io.Copy(io.Discard, resp.Body)清理 - 切勿依赖 defer resp.Body.Close() 就万事大吉 —— 关闭本身不等于读完
DefaultClient 直接使用会掩盖 transport 配置问题
很多项目直接用 http.Get() 或 http.DefaultClient.Do()，看似简单，实则完全继承 DefaultTransport 的保守参数（MaxIdleConns = 100 是全局总和，非 per-host），且无法针对性调优。
立即学习“go语言免费学习笔记（深入）”；
- 务必显式构造
*http.Client并传入自定义http.Transport - 不要复用同一个
*http.Client实例去访问差异巨大的后端（如同时连 S3 和本地服务）—— 应按目标 domain 分 client，各自配 transport - 注意
IdleConnTimeout（默认 90s）：太短会导致空闲连接过早淘汰，太长则占用 fd；建议设为 30–60s，配合业务 RTT 调整
真正难处理的不是参数本身，而是「body 是否读完」这个状态不可见、无日志、不报错，只默默让连接失效。线上观察到 TIME_WAIT 持续上涨，第一反应不该是改系统内核参数，而应检查所有 resp.Body.Close() 调用点是否伴随完整读取逻辑。
