Go http.Transport.Clone 怎样隔离客户端连接配置

多个 HTTP 客户端如果直接共用一个 http.Transport，最容易遇到的不是请求发不出去，而是某个客户端调整代理、连接池或 TLS 配置后，其他客户端也跟着变化。更稳妥的做法是先准备一份基础 Transport，再用 Clone() 为每个客户端创建副本，并在副本投入请求前完成个性化设置。

官方地址：https://pkg.go.dev/net/http#Transport.Clone

核心规则是：模板只保存公共配置，Clone 负责复制已配置的导出字段；每个副本绑定一个明确的 http.Client，请求开始后不再随意改动 Transport 字段。

为什么不能直接共享并修改同一个 Transport

http.Client 和 http.Transport 都适合创建后复用，也支持多个 goroutine 并发使用。但“可以并发使用”不等于“可以在请求运行时并发改配置”。如果客户端 A 需要走代理、客户端 B 不走代理，直接修改同一个 Transport 就会让配置所有权变得模糊。

base := http.DefaultTransport.(*http.Transport)

// 直接修改共享 Transport，会把后续请求都带入同一份变化。
base.MaxIdleConnsPerHost = 8

上面这段代码还把全局默认 Transport 当成了应用自己的配置对象。即使暂时没有第二个客户端，后续引入测试、后台任务或第三方组件后，也很难判断是谁修改了它。先复制出应用自己的模板，边界会清楚很多。

先配置一份可复用的基础模板

基础模板只放所有客户端都认可的设置，例如公共连接上限、空闲连接超时和统一的拨号函数。模板本身不负责某一个客户端的差异化代理或租户参数。

package main

import (
    "net/http"
    "time"
)

func newTransportTemplate() *http.Transport {
    // 复制默认 Transport，避免直接改动全局默认对象。
    tr := http.DefaultTransport.(*http.Transport).Clone()
    // 这些是所有客户端共享的基础连接策略。
    tr.MaxIdleConns = 64
    tr.MaxIdleConnsPerHost = 8
    tr.IdleConnTimeout = 30 * time.Second
    return tr
}

这里的模板已经是一个独立的 Transport。创建客户端时仍建议继续调用 Clone，让模板保持只读约定；这样多个客户端的后续修改不会落回模板。

在投入使用前克隆并修改副本

客户端差异化配置的顺序可以固定为“模板、克隆、修改、绑定”。例如两个客户端使用不同代理，但共享连接超时和空闲连接上限：

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

func newClient(template *http.Transport, proxyURL *url.URL) (*http.Client, *http.Transport) {
    // Clone 返回客户端专属 Transport，后续字段只修改这份副本。
    tr := template.Clone()
    if proxyURL != nil {
        // 代理函数只属于当前副本，不回写模板。
        tr.Proxy = http.ProxyURL(proxyURL)
    }
    // 每个客户端也可以拥有自己的主机级空闲连接上限。
    tr.MaxIdleConnsPerHost = 4
    return &http.Client{Transport: tr}, tr
}

示例中的 url.URL 需要从调用方传入，实际代码还要补齐 net/url 导入。关键不在代理本身，而在于 template.Clone() 之后才进行修改。若先改模板再克隆，隔离就已经失效了。

Clone 复制了什么，哪些状态仍要自己负责

官方文档把 Transport.Clone 定义为“复制导出字段的深拷贝”。这意味着常见的导出配置可以从模板带到副本，副本也拥有自己的 Transport 内部生命周期。它不等于把所有外部资源都神奇地复制一遍：

• 函数值、回调闭包和回调内部引用的对象，仍可能由多个副本共同使用。
• 模板里如果接入了自定义连接池、外部证书管理器或自定义 RoundTripper，要分别确认这些对象的并发与所有权约定。
• Clone 只解决 Transport 配置副本问题，不会替应用复制业务级缓存、CookieJar 或请求上下文。

var proxyA, proxyB *url.URL // 由调用方按客户端策略准备。
template := newTransportTemplate()
clientA, transportA := newClient(template, proxyA)
clientB, transportB := newClient(template, proxyB)

// 两个副本的字段可以分别调整，模板不再承担运行时状态。
transportA.MaxIdleConnsPerHost = 4
transportB.MaxIdleConnsPerHost = 16

_ = clientA
_ = clientB

不要把“导出字段已复制”理解成“所有深层业务对象都断开共享”。如果某个回调捕获了可变 map，真正的隔离仍要由业务代码显式完成。

绑定到 http.Client 后管理空闲连接

http.Client 的 Transport 通常持有连接缓存，因此客户端应该作为长生命周期对象复用。只有在客户端或 Transport 不再使用时，才考虑关闭空闲连接；关闭动作不会中断正在使用的连接。

func shutdownClient(transport *http.Transport) {
    if transport == nil {
        return
    }
    // 只关闭 keep-alive 空闲连接，不打断正在传输中的请求。
    transport.CloseIdleConnections()
}

如果应用有多个独立客户端，就分别保存它们的 Transport 引用，在对应生命周期结束时关闭对应副本。不要因为一次请求结束就关闭共享客户端的空闲连接，否则会失去连接复用的价值。

把配置修改限制在初始化阶段

Transport 可以被多个 goroutine 并发使用，但应用应把字段设置、Clone 和客户端绑定集中在初始化阶段。请求已经开始后，不要再通过共享指针随意改 Proxy、TLSClientConfig、连接上限等字段。

需要按租户、区域或网络出口切换策略时，优先为不同策略建立不同的 Transport 副本，并把副本作为不可变配置交给对应的客户端。这样读请求只使用连接资源，写配置只发生在构造阶段，排查问题时也能沿着“哪个客户端持有哪些副本”定位。

常见边界可以这样判断

Clone 后修改副本会影响模板吗？

对 Transport 导出配置而言，Clone 的目标就是建立副本，因此应把修改放在返回值上。但回调函数或外部对象内部的可变状态不属于“自动复制业务所有权”的范围，仍需单独处理。

每次请求都 Clone 一个 Transport 可以吗？

不建议。Transport 会缓存连接，官方建议复用它。按客户端、租户或网络策略创建有限数量的长期对象，比按请求创建更符合连接复用模型。

CloseIdleConnections 会中断正在请求的连接吗？

不会。它针对已经空闲的 keep-alive 连接；正在使用的连接不在这次关闭范围内。

最终可以把原则压缩成一句话：公共设置放模板，差异配置改副本，副本绑定长期客户端，生命周期结束再关闭空闲连接。