Go服务TIME_WAIT爆满主因是连接池未配对、响应体未读完、内核tcp_tw_reuse未开启；必须同步调大MaxIdleConnsPerHost与MaxConnsPerHost、完整消费resp.Body（非仅Close）、并启用tcp_timestamps和tcp_tw_reuse内核参数。
Go服务TIME_WAIT爆满，不是连接太多，而是连接池没配对、响应体没读完、内核复用没开——三者缺一不可。
为什么http.DefaultClient在高并发下必然堆满TIME_WAIT
直接用http.Get()或http.DefaultClient.Do()，等于把连接池交给默认http.Transport：它全局只允许MaxIdleConns = 100，且MaxIdleConnsPerHost = 2。每秒5000请求打向同一个后端（比如api.example.com:443），99%的请求都得新建连接——建完就关，立刻进TIME_WAIT。
更隐蔽的问题是：DefaultClient无法按目标域名分 transport，你用它同时连S3和本地gRPC服务，连接池会互相挤占，参数完全失焦。
- 必须显式构造
*http.Client，传入自定义http.Transport - 若服务访问多个差异大的后端（如
influxdb.internal和s3.amazonaws.com），应为每个 domain 单独建 client - 别信“复用client就行”，没配 transport 的 client 和没装引擎的车一样跑不动
MaxIdleConnsPerHost和MaxConnsPerHost怎么设才不翻车
MaxIdleConnsPerHost不是越大越好，它和MaxConnsPerHost必须协同：前者管“常驻空闲连接数”，后者管“最大并发连接上限”。失配会导致连接建了不用、立刻销毁，反而加剧TIME_WAIT。
-
MaxIdleConnsPerHost建议设为预期峰值 QPS 的 1/5～1/3（例如峰值 5000 QPS → 设 100～200） -
MaxConnsPerHost必须 ≥MaxIdleConnsPerHost，否则连接池阻塞，请求卡在waiting for connection - 避免
MaxConnsPerHost远大于MaxIdleConnsPerHost（如 1000 vs 10），这会让大量连接只用一次就丢弃 -
IdleConnTimeout设 30–60 秒，太短（120s）浪费 fd
resp.Body.Close() ≠ 读完响应体，这才是TIME_WAIT暴增的真凶
Go的连接复用逻辑非常严格：只有完整消费resp.Body，transport 才敢把连接放回 idle 池。只调defer resp.Body.Close()，等于告诉 transport：“这连接可能还有残留数据，别复用，直接关”——于是强制关闭，触发TIME_WAIT。
- 需要读 body：用
json.NewDecoder(resp.Body).Decode(&v)，它内部会读完流；但 decode 失败时，必须补io.Copy(io.Discard, resp.Body) - 不需要 body：必须显式丢弃，
io.Copy(io.Discard, resp.Body)（Go 1.19+）或io.Copy(ioutil.Discard, resp.Body)（旧版） - 绝对不要依赖
defer resp.Body.Close()就以为万事大吉 - 如果用了
http.Response.StatusCode就返回，却没碰resp.Body，100%触发连接销毁
内核参数不调，应用层再努力也白搭
即使 Go 客户端全配对、body 全读完，单靠应用层无法绕过 TIME_WAIT 的系统级限制。Linux 默认只给 3.2 万个临时端口，而 TIME_WAIT 默认持续 120 秒（2×MSL），意味着每秒超过 278 个短连接就会开始堆积。
- 必须开
net.ipv4.tcp_timestamps = 1（tcp_tw_reuse 前提） - 必须开
net.ipv4.tcp_tw_reuse = 1（客户端主动复用 TIME_WAIT socket） - 建议设
net.ipv4.tcp_fin_timeout = 30（加快 FIN_WAIT_2 转换节奏） - 扩端口：
net.ipv4.ip_local_port_range = 1024 65535 - 提桶上限：
net.ipv4.tcp_max_tw_buckets = 200000（防 overflow 静默丢包） - 禁用
tcp_tw_recycle——云环境、NAT、K8s 下必出连接失败
真正难处理的不是哪个参数该设多少，而是 body 消费逻辑散落在几十个 HTTP 调用点里，漏掉一处，整条链路的连接复用就崩了。
