Go net/http Transport.CloseIdleConnections 何时该调用：连接池复用与发布切换

服务切换到新上游后，Go 客户端还可能继续复用旧连接。这个现象通常不是 http.Client “记住了旧 IP”，而是共享的 Transport 正在复用 keep-alive 连接。CloseIdleConnections 适合放在切换窗口清理已经空闲的连接，但它不会中断正在执行的请求，也不能代替关闭响应体。

发布切换时可以调用 Client.CloseIdleConnections()，让空闲连接退出连接池；正在使用的连接会继续完成，后续请求再按 Transport 的规则建立或复用连接。

先把“旧连接还在用”与“旧地址还在解析”分开

排查时最容易把两个问题混在一起：一类是 DNS、服务发现或代理仍然返回旧地址；另一类是地址已经变化，但已有的 TCP/TLS 连接还处在 keep-alive 池里。本文只讨论后一类。

Go 文档明确说明，Transport 默认会缓存连接供后续请求复用，而且它可以安全地被多个 goroutine 共同使用。因此，客户端应该长期复用一个 Transport，而不是每次请求都创建一个新的 Transport。

一个最小客户端如何走过连接复用边界

下面的代码刻意把客户端和 Transport 放在长期存活的结构体中。请求从 RoundTrip 进入 Transport 后，第一轮请求完成且响应体关闭，连接才可能回到 keep-alive 池。

type UpstreamClient struct {
    client *http.Client
}

func NewUpstreamClient() *UpstreamClient {
    tr := &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 20,
        IdleConnTimeout:     90 * time.Second,
    }
    return &UpstreamClient{client: &http.Client{Transport: tr}}
}

func (u *UpstreamClient) Get(ctx context.Context, url string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return err
    }
    resp, err := u.client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    _, err = io.Copy(io.Discard, resp.Body)
    return err
}

这里有两个容易漏掉的动作：defer resp.Body.Close() 负责释放响应体，读取到 EOF 则更有利于连接被复用。CloseIdleConnections 只是在连接已经空闲之后做池清理，它不是响应体的替代品。

发布切换时应该清理哪一批连接

假设服务发现已经指向新上游，但共享客户端池里还留着旧连接。切换动作可以放在配置刷新成功之后：

func (u *UpstreamClient) AfterUpstreamSwitch() {
    u.client.CloseIdleConnections()
}

Client.CloseIdleConnections 会检查底层 Transport 是否提供同名能力，标准 *http.Transport 支持该方法时就会转发。图中用 idle connection（空闲连接）表示可被清理的池内连接，用 in-use connection（正在使用的连接）表示仍在上传请求体或读取响应的连接；后者不会被这次调用硬切断。

这正是它适合发布切换的原因：让尚未开始下一次请求的旧连接退出池，同时不把正在执行的业务请求变成一次人为网络错误。新请求是否命中新上游，还要结合服务发现刷新、代理缓存和应用层路由一起确认。

一个可回滚的切换顺序

1. 先更新服务发现或上游配置，并确认新目标可以建立健康连接。
2. 保留共享的 http.Client 与 Transport，不要在切换时把每个请求都改成新建 Transport。
3. 配置刷新成功后调用 Client.CloseIdleConnections()，只清理空闲池。
4. 观察新旧上游的请求量、错误率和连接建立失败；异常时回滚发现配置，再按同样方式处理空闲连接。

这里不要把“调用完成”当成“所有旧请求都结束”。这次调用没有等待正在使用的连接，也没有替应用层追踪长轮询、WebSocket 或流式响应。长连接应该由业务代码单独设计退出和重连策略。

常见问题：连接池清理的几个边界

每次请求都 new 一个 Transport 会更干净吗？

通常不会。这样会失去连接复用，并可能制造大量连接和握手开销。Transport 应该复用，生命周期与客户端或上游配置管理器一致。

调用 CloseIdleConnections 能取消慢请求吗？

不能。取消慢请求应使用带取消能力的 context.Context，并让请求代码处理取消后的响应体关闭和错误记录。

响应体只读一小段也能复用连接吗？

不能简单假设。是否可复用取决于响应体是否正确关闭、是否读完以及协议实现的具体行为。需要复用时，优先按业务需要读取到 EOF，再关闭响应体。

调用后如何确认新上游生效？

不要只看连接池方法返回，因为该方法没有返回值。应在应用日志、上游访问日志和指标中用请求时间窗口核对新目标，同时单独记录配置刷新成功与清理动作。

把判断落到一条检查清单

• 是否长期复用了同一个 http.Transport？
• 每个成功响应是否都关闭了 Response.Body？
• 切换前是否先确认新上游健康且配置刷新成功？
• 清理动作是否只针对空闲连接，未被误当成全量断连接口？
• 慢请求、流式响应和 WebSocket 是否有独立的结束策略？

一句话记忆：Transport 负责连接复用，Response.Body.Close 负责响应生命周期，CloseIdleConnections 负责在合适的切换窗口清理闲置 keep-alive 连接。把这三个职责分开，发布时就不容易为了“换新连接”误伤正在运行的请求。