Go http.Transport.Clone 怎么隔离客户端配置：连接池复用、Header 边界与并发改造

线上服务往往会同时访问主站、对象存储和内部 API。把同一个 http.Transport 直接改来改去，短期看不出问题，流量一上来就容易出现代理、TLS 或空闲连接参数互相污染。更稳的做法是把一份已经核对过的 Transport 当作配置基线，用 Clone 派生少量客户端，再把每次请求的 Header 放回请求本身。

为什么“共享一个 Transport 再临时改参数”会变得危险

http.Client 和 http.Transport 都可以被多个 goroutine 并发使用，官方也建议复用它们。问题出在“复用”和“修改”不是一回事：请求进行期间再修改代理、TLS 配置或空闲连接参数，调用方很难判断当前请求究竟读到了哪一份配置。

另一种常见误解是把 Clone 当成完整运行时快照。它返回导出字段的深拷贝，适合派生配置；底层连接是否继续复用，则取决于每个 Transport 自己建立和管理的连接状态。配置隔离后，仍然要把响应体正确关闭，否则连接复用的收益会先被自己的资源管理抵消。

Transport.Clone 适合复制哪些配置

先建立一份只读意味明确的基线。真实项目里通常在初始化阶段完成 TLS、代理和连接上限设置，之后不再原地修改它：

base := http.DefaultTransport.(*http.Transport).Clone()
base.MaxIdleConns = 100
base.MaxIdleConnsPerHost = 20
base.IdleConnTimeout = 90 * time.Second

internal := base.Clone()
internal.Proxy = nil

external := base.Clone()
external.MaxIdleConnsPerHost = 8

internalClient := &http.Client{Transport: internal, Timeout: 8 * time.Second}
externalClient := &http.Client{Transport: external, Timeout: 15 * time.Second}

这里的边界很清楚：internal 和 external 是两份客户端级配置，超时时间则属于 Client。不要在请求已经发出后再改这些字段；把差异集中在初始化代码里，审查和压测都更简单。

一份基线是否应该派生很多份

不建议按用户、请求或 goroutine 派生 Transport。Transport 维护连接缓存，按请求复制会让连接池数量膨胀，反而增加握手和文件描述符压力。通常按网络边界或服务端点划分：例如一个内部服务客户端、一个需要代理的外部客户端，数量稳定后再做指标核对。

请求级 Header 不要跟着 Transport 一起共享

鉴权令牌、租户编号和链路追踪 ID 都是请求级数据。最小安全写法是每次创建请求后写入自己的 Header：

func doJSON(ctx context.Context, client *http.Client, url, token, tenant string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, url, nil)
    if err != nil {
        return err
    }
    req.Header.Set("Authorization", "Bearer "+token)
    req.Header.Set("X-Tenant-ID", tenant)
    req.Header.Set("Accept", "application/json")

    resp, err := client.Do(req)
    if err != nil {
        return err
    }
    defer resp.Body.Close()
    if resp.StatusCode = 300 {
        return fmt.Errorf("unexpected status: %s", resp.Status)
    }
    return nil
}

如果上层已经有一份公共 Header，也要先用 Header.Clone 得到副本，再追加当前请求的字段。不要把一个 http.Request 放进全局变量反复改 Header；这类写法即使偶尔“看起来能跑”，在并发压测下也可能把 A 请求的租户字段带到 B 请求。

并发改造后用三个信号验收

测试时可以给服务端返回请求头摘要，并在客户端日志中带上请求 ID。重点不是只看是否返回 200，而是确认并发交错后每个请求仍携带自己的值。压测结束或配置热切换时，若确实需要清理闲置连接，再调用对应 Transport 的 CloseIdleConnections，不要把它当作日常请求流程的一部分。

常见问题：Transport.Clone 的几个边界

Clone 能不能替代每个请求的超时

不能。Transport 的连接策略和 Client 的整体超时是客户端级配置；单个请求还可以通过 context.WithTimeout 设置更细的截止时间。超时上下文应绑定到当前请求，不能写进共享客户端状态。

修改 Clone 返回的副本会影响原 Transport 吗

对导出配置字段，Clone 的目的就是让派生副本独立修改。仍然不要把这个结论扩展到所有自定义 RoundTripper 或外部引用：如果字段里挂着自己维护的可变对象，应该查清它的所有权和并发规则。

为什么请求成功了连接仍然没有复用

先查响应体是否关闭、是否读到合适的位置，再查是否为同一 Transport、服务端是否支持 Keep-Alive，以及是否被代理或协议升级改变了连接行为。只看客户端返回状态码，无法证明连接池真的命中了。

把 Transport 当作稳定边界

一份基线 Transport 负责稳定的网络策略，少量 Clone 副本负责服务边界差异，Header 和超时负责单次请求差异。这样的层次划分既保留连接复用，也让并发代码不必争抢一份会变化的配置。上线前用请求头串线测试和连接指标各验一次，通常比继续堆更多全局客户端变量更容易维护。