Go长连接本身不导致TIME_WAIT爆表，根本原因是MaxIdleConnsPerHost默认为2致连接无法复用，且resp.Body未读完就Close破坏复用逻辑；须同步调大MaxIdleConnsPerHost与MaxConnsPerHost，并确保完整消费响应体。
go里所谓“长连接”本身不会导致time_wait爆表；真正让端口迅速耗尽的，是连接池配错 + 响应体没读完这两件事同时发生。
MaxIdleConnsPerHost设太小，连接根本复用不起来
默认http.Transport的MaxIdleConnsPerHost = 2，意味着每个目标域名（比如api.example.com:443）最多只缓存2个空闲连接。QPS一过百，绝大多数请求就只能新建连接——建完立刻关，每条都进TIME_WAIT。
- 单后端服务（如InfluxDB、自建API），建议设为
MaxIdleConnsPerHost = 100或更高，与峰值QPS匹配 - 必须同步设置
MaxConnsPerHost ≥ MaxIdleConnsPerHost，否则连接池会阻塞等待，反而引发超时 - 避免
MaxConnsPerHost远大于MaxIdleConnsPerHost：前者管上限，后者管常驻；失配会导致连接建了不用、立刻销毁，徒增TIME_WAIT
resp.Body.Close() ≠ 读完响应体，复用逻辑直接失效
Go的连接复用有一个硬性前提：响应体必须被完整消费。只调resp.Body.Close()而不读取或丢弃body，transport会认为连接可能残留未读数据，拒绝复用，强制关闭连接——这是TIME_WAIT激增最隐蔽的主因。
- 无论是否需要body内容，都必须显式处理：用
io.Copy(io.Discard, resp.Body)（Go 1.19+）或io.ReadAll(resp.Body) - 若用
json.NewDecoder(resp.Body).Decode(&v)，它内部会读完流；但decode失败后，仍要补上io.Copy(io.Discard, resp.Body) -
defer resp.Body.Close()不是万能解药——关闭不等于读完，别信这个惯性操作
别用http.DefaultClient，它藏不住transport配置问题
直接调http.Get()或http.DefaultClient.Do()，等于继承DefaultTransport的保守参数（MaxIdleConns = 100是全局总和，非per-host），且无法针对性调优。
- 务必显式构造
*http.Client并传入自定义http.Transport - 不同目标域（如S3 vs 本地gRPC网关）应分client管理，各自配transport，避免参数互相干扰
-
IdleConnTimeout建议设为30–60s：太短导致空闲连接过早淘汰，太长则长期占着fd
真正难处理的不是参数值本身，而是body是否真的被读完了——这一步没有日志、没有报错、复用静默失败，却在netstat里堆出上万个TIME_WAIT。每次改完transport参数，务必用io.Copy(io.Discard, resp.Body)兜底，再压测验证。
立即学习“go语言免费学习笔记（深入）”；
