go标准库http.client不主动探活空闲连接，仅依赖复用时写请求头失败即丢弃、idleconntimeout强制淘汰老化连接及tcp keepalive内核机制；http/2下由协议层自动处理健康检测。
Go 标准库的 http.Client 不主动“探活”空闲连接，它依赖操作系统 TCP keepalive 和服务端超时配合来清理失效连接；真正起作用的是被动检测 + 复用时失败重试，不是定期心跳。
为什么没有主动探活逻辑
Go 的 http.Transport 没有内置定时 ping 或发送空帧来检查连接是否存活。它的设计哲学是轻量、无状态、按需复用——连接归还进 idle pool 后，只等下次请求来取；取的时候发现写失败（如 write: broken pipe 或 read: connection reset by peer），就丢弃该连接、新建一个。
- 主动探活会增加资源开销（goroutine、系统调用、网络流量），违背 Go HTTP 客户端“简单可靠”的定位
- TCP 层已有
net.Conn.SetKeepAlive（默认开启），内核会在连接空闲时发 TCP keepalive probe，但周期长（通常 2 小时起）、不可控、且不保证应用层感知 - HTTP 层的保活责任落在两端：客户端靠
IdleConnTimeout主动淘汰“太老”的空闲连接，服务端靠自身IdleTimeout关闭“太久没动静”的连接
实际复用时如何发现连接已断
当 http.Transport 从 idle pool 取出一个连接准备发请求时，会做最小可行性检查：尝试写入请求头。一旦底层 Write 返回错误，就立即废弃该连接，走新建流程。
- 常见错误包括：
write: broken pipe、read: connection reset by peer、i/o timeout（若连接被中间设备静默断开） - 这个过程对上层透明，
client.Do()仍会成功返回响应（只要重试成功），但日志或监控中可能看到net/http: Transport failed to reuse idle connection - 注意：这个“失败即丢弃”行为仅发生在复用阶段，不会在 idle 期间轮询检查
IdleConnTimeout 是唯一可控的“软探活”手段
IdleConnTimeout 不是探活，但它是最有效的预防措施——它限制连接在池中能“躺平”的最长时间，强制提前释放，避免复用时撞上已被服务端关闭的连接。
- 设为比服务端
keepalive_timeout短 5～10 秒（例如 Nginx 默认 75s → 客户端设60 * time.Second） - 若设得太长（如 120s），而服务端 75s 就关了连接，那池子里一堆“僵尸连接”，每次复用都失败重连
- 若设得太短（如 10s），连接频繁新建，失去复用意义；尤其对低频请求服务，几乎等于禁用 idle pool
HTTP/2 下更不需要探活
HTTP/2 天然支持多路复用和流级健康检测：PING 帧和服务端 SETTINGS 更新可及时暴露连接异常，GOAWAY 也能优雅通知客户端停止发新流。Go 的 http2.Transport 会自动处理这些，无需额外配置探活逻辑。
- 此时
MaxIdleConnsPerHost实际失效（单 host 通常只需 1 个连接），IdleConnTimeout仍控制底层 TCP 连接生命周期 - 但要注意：若代理（如 Nginx）未正确透传 HTTP/2 帧或降级到 HTTP/1.1，探活失效问题会回退到 HTTP/1.1 模式
真正要盯住的不是“怎么探活”，而是让 IdleConnTimeout 和服务端超时严丝合缝，并确保每次请求后都调用 resp.Body.Close() ——漏掉后者，连接根本进不了 idle pool，探活再强也白搭。
