连接未复用是因为Keep-Alive需客户端和服务端协同生效，常见原因包括：Transport未配置MaxIdleConnsPerHost、未调用resp.Body.Close()、IdleConnTimeout过短，或Client未复用导致连接池失效。
为什么连接没复用，明明开了 Keep-Alive
Go 的 http.Client 默认确实启用 Keep-Alive，但「开启」不等于「复用成功」。常见原因是 Transport 配置缺失或误用：
• 每次请求都新建 &http.Client{} 或直接用 http.DefaultClient（后者无法定制 Transport）
• 自定义了 http.Transport 却没设 MaxIdleConnsPerHost，导致默认 100 连接池在高并发下快速排队
• 忘记调用 resp.Body.Close()，连接永远卡在 idle 状态，无法归还给池
• IdleConnTimeout 设得太短（如 5 秒），空闲连接刚建好就被回收
关键 Transport 参数怎么设才合理
参数不是越大越好，需结合目标服务数量、QPS 和延迟容忍度来调：
• MaxIdleConns：全局最大空闲连接数，建议设为 200～500；若只调一个后端，设 0（不限制）也常见
• MaxIdleConnsPerHost：单 host 最大空闲连接数，比 MaxIdleConns 更关键；一般设为 100，高并发可提至 200
• IdleConnTimeout：建议 60 * time.Second，比多数服务端的 keepalive_timeout（Nginx 默认 75s）略短，避免被服务端主动断连
• TCPKeepAlive：设为 30 * time.Second 可探测中间网络断连，尤其在长链路或云环境中有用
• ForceAttemptHTTP2：保持默认 true，HTTP/2 多路复用能显著降低连接压力
Client 实例和 Transport 能不能共享
必须共享，且方式有明确约束：
• http.Client 是线程安全的，应作为包级变量或依赖注入单例使用，**禁止在 handler 或循环里 new Client**
• 若需不同超时策略（如一个接口 5s，另一个 30s），应新建 http.Transport，再传给新 http.Client；不要新建 Client 却复用旧 Transport——Transport 才是连接池载体
• 多个 Client 共享同一个 Transport 是安全的，也是推荐做法；但 Transport 本身不可并发修改字段（如运行中改 MaxIdleConns）
• 不要用 http.DefaultClient 做业务请求，它底层 Transport 无法调整参数，且与其他库冲突风险高
哪些场景该关掉 Keep-Alive
Keep-Alive 是优化手段，不是必须项。以下情况主动禁用更稳妥：
• 极低频调用（如每小时一次配置同步），开 Keep-Alive 只是白占内存和 TIME_WAIT 端口
• 对接老旧 Nginx 或自研代理，对方未正确处理 Connection: keep-alive 头，导致复用后请求卡死或返回乱码
• 需要抓包分析单次请求完整生命周期（比如排查 TLS 握手异常），临时设 DisableKeepAlives = true 可强制短连接
• 客户端侧资源极度受限（如嵌入式设备），连接池维护开销 > 复用收益
最易被忽略的一点：连接复用效果无法靠日志肉眼判断，得看 transport.IdleConnMetrics（Go 1.19+）或监控 http.Transport 的 IdleConn 数量波动。没有指标支撑的调参，只是凭感觉猜。
