Go 问答：http.Transport.CloseIdleConnections 关闭了哪些连接：空闲池与并发请求边界

服务刚做完一次上游切换，连接池里还留着旧主机的 keep-alive 连接。此时调用 http.Transport.CloseIdleConnections，确实可以清掉已经完成请求、正在空闲等待复用的连接；正在被请求占用的连接不会被它打断。这个边界决定了它适合“切换后清理旧连接”，不适合拿来取消当前请求。

CloseIdleConnections 只关闭 Transport 已建立且当前 idle 的 keep-alive 连接；要停止正在执行的请求，应使用请求上下文或更高层的取消机制。

先把“关闭连接”限定到客户端 Transport

http.Client.CloseIdleConnections 会把调用转交给底层 Transport；直接使用自定义 RoundTripper 时，真正提供这个方法的是 *http.Transport。Go 官方文档将它定义为关闭先前请求连接后、现在处于 keep-alive idle 状态的连接，并明确说明不会中断正在使用的连接。

因此，下面这段代码表达的是“清理复用池”，不是“终止请求”：

transport := &http.Transport{
    MaxIdleConnsPerHost: 8,
    IdleConnTimeout:     90 * time.Second,
}
client := &http.Client{Transport: transport}

// 请求完成后，主动清理当前没有被使用的 keep-alive 连接
transport.CloseIdleConnections()

调用链可以压缩成：client.Do 把请求交给 Transport.RoundTrip，响应体关闭后连接才有机会回到 idle 池，随后 CloseIdleConnections 才有可清理对象。

哪些连接会被清理，哪些不会

把连接分成两类更容易判断：第一类是请求已经结束、连接等待下一次复用；第二类是仍在发送请求或读取响应。前者是 CloseIdleConnections 的目标，后者不在它的职责范围内。

• 会处理：之前请求建立、当前处于 keep-alive idle 状态的连接。
• 不会打断：当前仍在使用的连接，包括正在读取响应体的请求。
• 不保证立即复用：后续请求仍可能重新拨号，具体取决于目标地址、协议与 Transport 配置。

这里有一个经常被忽略的前置条件：如果响应体没有读到 EOF 或没有关闭，Transport 可能无法复用持久连接。也就谈不上把它作为“旧连接”交给主动清理。

resp, err := client.Get(url)
if err != nil {
    return err
}
defer resp.Body.Close()

_, err = io.Copy(io.Discard, resp.Body)
return err

下面的状态图只保留正文真实出现的三个节点：请求经过 Transport.RoundTrip，响应体关闭后进入 idle，主动调用 CloseIdleConnections 才会清理 idle 分支；使用中分支继续运行。

与 IdleConnTimeout、MaxIdleConnsPerHost 怎么分工

IdleConnTimeout 是时间策略：连接在 idle 状态超过配置时长后自动关闭，零值表示不限制。MaxIdleConnsPerHost 是容量策略：控制每个主机最多保留多少条 idle keep-alive 连接。CloseIdleConnections 则是不等时间、不等容量的主动动作。

例如灰度切换上游地址时，可以先让请求自然结束，再主动清理旧 Transport 的 idle 连接；如果只是常规长驻客户端，通常让 IdleConnTimeout 和连接上限负责日常回收即可。

不要用它取消正在执行的请求

如果目标是让一个卡住的请求尽快结束，应给请求绑定可取消的 context.Context，并在截止时间到达后检查返回的错误。CloseIdleConnections 没有这个语义，调用它后正在使用的请求仍可能继续等待响应。

另外，Transport 应该复用而不是每个请求创建一个；官方文档说明 Transport 可以被多个 goroutine 并发安全使用。频繁新建 Transport 会失去连接复用，也会让“清理哪一个连接池”变得含糊。

相关问题

调用 CloseIdleConnections 会影响下一次请求吗？

可能会。已有 idle 连接被关闭后，下一次请求通常需要重新建立连接，但请求仍由同一个 Transport 负责。

响应体只调用 Close 不读完，会发生什么？

Transport 可能无法复用这条持久连接。是否能复用取决于响应体是否读到 EOF 以及关闭时机，不能只把 Close 当成完整读取的替代品。

Client.CloseIdleConnections 和 Transport.CloseIdleConnections 有区别吗？

Client 方法会对其底层 Transport 做能力转发；若底层 RoundTripper 没有对应方法，则不会产生清理动作。直接持有具体的 *http.Transport 时，调用 Transport 方法更直观。

最后的判断标准

遇到上游切换、证书轮换或明确要释放空闲连接时，使用 CloseIdleConnections；遇到当前请求超时或取消，使用请求上下文；遇到常态连接池治理，检查 IdleConnTimeout、MaxIdleConnsPerHost 与响应体关闭方式。把这三个问题分开，才能知道一次“关闭”到底解决的是连接复用，还是请求生命周期。