go标准库http.transport不主动探活空闲连接，仅复用前轻量检查；是否有效取决于idleconntimeout与服务端keep-alive配置对齐，tcpkeepalive开启内核级探测，idleconntimeout仍需合理设置。
Go 标准库的 http.Transport 不会主动“探活”空闲连接，它只在复用前做轻量级可用性检查；真正决定连接是否有效、是否该被丢弃的，是 IdleConnTimeout 和服务端的 keep-alive 配置对齐程度。
为什么 Transport 不主动 ping 探活
Go 的 http.Transport 设计上不发送 HTTP-level 的心跳或 OPTIONS 请求去探测连接是否还活着。它依赖的是：连接归还进 idle pool 后，只记录“最后使用时间”，超时即关闭；下次复用时，尝试写请求头——若底层 TCP 连接已断（如服务端静默关闭），会立即触发 read: connection reset by peer 或 write: broken pipe，此时 transport 会丢弃该连接、新建一个。
- 这种“懒探活”策略省去了额外 IO 和线程开销，但要求客户端和服务端的空闲超时必须严格对齐
- 若你看到复用失败后重连延迟高，大概率不是没探活，而是服务端先关了连接，而客户端还不知道
- HTTP/2 下更不需探活：协议层自带流控制和 GOAWAY 帧，transport 会根据帧反馈自动剔除失效连接
真正起作用的“保活”参数是 TCPKeepAlive
TCPKeepAlive 是唯一真正开启操作系统级探活的开关，它让内核周期性发送 TCP keepalive 包（非 HTTP）：
- 默认值为
0（禁用），即完全不发 TCP-level 心跳 - 设为
30 * time.Second后，内核会在连接空闲超过该时间后，每 30 秒发一次探测包；连续 3 次无响应则标记连接为 dead - 这对云环境、NAT 网关、长链路中间设备特别有用——它们常会单向丢弃“安静”的连接
- 注意：它不能替代
IdleConnTimeout，只是补充；即使 TCP 层探测到连接存活，若已超IdleConnTimeout，transport 仍会主动关闭
如何验证连接是否被提前断开
别信响应头或日志，直接看连接状态：
- 用
ss -tn sport = :443 | grep ESTAB观察同一目标 IP 的 ESTABLISHED 连接数是否稳定，突降说明被服务端强制关闭 - 抓包过滤
tcp.flags.fin == 1 or tcp.flags.rst == 1，看 FIN/RST 是谁先发的：服务端先发 → 你IdleConnTimeout设太长；客户端先发 → 可能是 context cancel 或超时触发 - 加 transport 日志：包装
DialContext，打印每次net.Conn的RemoteAddr()和创建时间，连续请求若地址不同，说明没复用
容易被忽略的 HTTP/2 多路复用干扰点
HTTP/2 下，MaxIdleConnsPerHost 实际失效，但 IdleConnTimeout 依然控制底层 TCP 连接生命周期：
- 如果服务端支持 HTTP/2，但你的 client 因 TLS 配置问题（如
NextProtos漏掉"h2"）降级到 HTTP/1.1，复用行为会突然退化——此时排查重点是 TLS 握手日志和resp.Proto - HTTP/2 连接可承载成百上千个并发流，但底层 TCP 连接只有一个；若这个连接被中间设备 kill，所有流都会中断，表现像“集体超时”
- 此时
TCPKeepAlive尤其关键：它能让 TCP 层提前发现连接断开，避免后续流全部卡在 write 阻塞上
