Go transport 如何限定Transport 生命周期

如果一个 Go 服务需要“限定 Transport 生命周期”，最稳妥的做法不是每次请求都新建它，而是先把边界定成：Request 短生命周期，http.Client 跟随一个业务组件，http.Transport 跟随这个组件或进程；组件退出、上游配置切换时，再有计划地清理空闲连接。这样既保留连接复用，也不会让某个请求偷偷拥有一整套连接池。

官方资料：https://pkg.go.dev/net/http

Transport 的生命周期通常应长于单次请求、短于或等于它所属的客户端组件。只有代理、TLS、租户隔离等配置边界真正不同，才值得拆成多个 Transport；配置变化时用独立副本承接新流量，退出时清理空闲连接。

先区分请求、Client 和 Transport 的生命周期

我在长期运行的服务里最先改掉的习惯，是把 http.Transport 写进“调用一次就返回”的函数。Transport 默认会缓存连接供后续使用，官方也明确建议复用它；Client 和 Transport 都可以被多个 goroutine 并发使用。把它们放在请求函数内，等于每次调用都放弃已有连接池。

把 Transport 放进可关闭的客户端组件

一个小型封装足以把创建和释放动作集中起来。请求方法只接收上下文和目标地址，不负责制造连接池；服务关闭时由同一个组件调用 CloseIdleConnections。示例中的 defer 关闭响应体是请求边界，组件的 Close 则是 Transport 边界。

package clientbox

import (
    "context"
    "io"
    "net/http"
    "time"
)

// ClientBox 让一组请求共享同一个 Transport，并提供统一的退出入口。
type ClientBox struct {
    client    *http.Client
    transport *http.Transport
}

// New 创建一次客户端组件；调用方应在服务生命周期内复用返回值。
func New() *ClientBox {
    tr := &http.Transport{
        MaxIdleConns:        100,
        MaxIdleConnsPerHost: 8,
        IdleConnTimeout:     90 * time.Second,
    }
    return &ClientBox{
        transport: tr,
        client:    &http.Client{Transport: tr},
    }
}

// Fetch 只管理一次请求的 Response.Body，不在这里创建或销毁 Transport。
func (b *ClientBox) Fetch(ctx context.Context, target string) ([]byte, error) {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, target, nil)
    if err != nil {
        return nil, err
    }
    resp, err := b.client.Do(req)
    if err != nil {
        return nil, err
    }
    defer resp.Body.Close() // 请求结束前释放响应体，避免把连接边界留给调用方。
    return io.ReadAll(resp.Body)
}

// Close 只清理空闲连接，不中断仍在处理中的请求。
func (b *ClientBox) Close() {
    b.transport.CloseIdleConnections()
}

这段代码的数值只是边界示例，实际容量应结合上游数量和并发量决定。组件创建时导入 time，而不是把超时字段写成无单位整数；重点是所有请求共享一个组件，而不是复制成每次调用一套对象。

按配置边界拆分而不是按请求拆分

并不是“全进程只能有一个 Transport”。如果两个上游必须使用不同代理、TLS 客户端配置或连接上限，它们就有理由各自拥有 Transport。相反，只因为两个请求的 URL 不同，并不足以拆分；同一个 Transport 本来就会按目标主机管理连接。

已经开始使用的 Transport 不适合被请求协程随意改字段。要从一套基础策略派生新策略，可以复制导出配置，再把新实例交给新的客户端：

package clientbox

import (
    "net/http"
    "net/url"
)

func cloneForProxy(base *http.Transport, proxy func(*http.Request) (*url.URL, error)) *http.Transport {
    // Clone 返回导出字段的深拷贝，避免把新代理写回正在服务的实例。
    next := base.Clone()
    next.Proxy = proxy
    return next
}

// 使用新 Transport 承接新请求；旧实例仍负责收尾已经发出的请求。
func newClient(tr *http.Transport) *http.Client {
    return &http.Client{Transport: tr}
}

Clone 复制的是导出字段，适合从一套基础策略派生新实例；它不是“把旧连接池瞬移到新对象”。旧客户端不能在新客户端刚接管时立即销毁，否则仍在使用的请求会受到影响。

用连接参数限定空闲和并发范围

生命周期不是单一的秒数，还包括“允许同时存在多少连接”。MaxIdleConns 管所有主机的空闲连接总量，MaxIdleConnsPerHost 管单主机空闲连接数；MaxConnsPerHost 才覆盖拨号中、活动和空闲连接。IdleConnTimeout 只描述空闲 keep-alive 连接可以保留多久，不等于请求超时。

transport := &http.Transport{
    MaxIdleConns:        100, // 所有目标主机共享的空闲连接总上限。
    MaxIdleConnsPerHost: 8,   // 单个目标主机保留的空闲连接上限。
    MaxConnsPerHost:     64,  // 单主机拨号中、活动、空闲连接的总上限。
    IdleConnTimeout:     90 * time.Second, // 只约束空闲 keep-alive 连接。
}
client := &http.Client{
    Transport: transport,
    Timeout:   15 * time.Second, // 整体请求上限，和空闲连接回收是两件事。
}

如果服务中有十几个上游，优先估算每个上游的并发和响应时间，再决定每主机上限；不要把 MaxIdleConnsPerHost 当作“请求速度”开关。连接池的大小影响复用和等待，不能替代上下文取消、响应体收尾或服务级超时。

在变更和退出时收口生命周期

配置热切换时可以采用“双实例”思路：先用 Clone 或新配置构造新 Transport，让新请求进入新客户端；旧客户端继续处理已经发出的请求，等一段由业务决定的排空时间后，再对旧 Transport 调用 CloseIdleConnections。该方法把“停止接收新流量”和“清理旧空闲连接”分成两件事。

不要在每次请求结束时调用 CloseIdleConnections，那会把刚建立的复用池不断清空；也不要把“关闭 Client”理解成取消所有请求。真正的请求取消应使用请求上下文，Transport 的关闭动作则负责它拥有的空闲连接。最终可以按下面四项复查：

• 创建位置是否在请求函数之外，且不同配置是否有明确的 Transport 所有者。
• 请求成功、非 2xx 和读取失败路径是否都关闭 Response.Body。
• 连接参数是否分别对应空闲总量、单主机空闲量、单主机总量和空闲时长。
• 切换与退出是否先停止新流量，再清理旧实例的空闲连接。

常见问题

一个服务只能复用一个 Transport 吗？

不需要。相同代理、TLS 和连接策略可以共享；真正不同的配置或隔离要求可以拆分。关键是按配置边界拆，而不是按每次请求拆。

调用 CloseIdleConnections 会中断正在下载的响应吗？

官方语义是关闭已经处于空闲 keep-alive 状态的连接，不中断当前正在使用的连接。正在下载的响应仍应由请求上下文和 Response.Body.Close 管理。

IdleConnTimeout 能代替 Client.Timeout 吗？

不能。前者只约束空闲连接的保留时间，后者是客户端层面的请求时间限制。两者解决的对象不同，通常需要结合上下文超时一起设计。