Go http.Transport.Clone 为什么仍会共享部分底层状态

http.Transport.Clone 确实会返回一个新的 Transport，但“新的 Transport”不等于从它能访问到的每个对象都被递归复制。最重要的边界是：连接池、锁、活动请求和每主机连接计数属于 Transport 的未导出运行时状态，不会被复制；回调函数、接口值以及浅拷贝配置内部的引用，则仍可能指向同一个外部对象。

官方文档：https://pkg.go.dev/net/http

先排除误解：Clone 不会共享连接池

http.Transport 会缓存连接，官方建议复用 Transport，并说明它可以被多个 goroutine 并发使用。Clone 的实现会新建一个 Transport，再复制可配置的导出字段；旧实例内部已经建立的空闲连接、等待队列、锁、每主机连接计数以及活动请求不会进入新实例。

因此，如果两个 Client 分别使用原 Transport 和克隆后的 Transport，它们会各自建池、各自复用连接。关闭一边的空闲连接，也不会把另一边的池清掉。标题里的“共享部分底层状态”，准确说是共享某些导出配置背后可达的对象，而不是共享 Transport 自己的未导出运行时状态。

为什么新实例仍能改到同一份数据

函数值可以复制，却无法像结构体字段那样把闭包环境递归复制。下面把同一个闭包赋给 DialContext，再调用 Clone。两个字段都能执行该闭包，闭包捕获的 *dialStats 仍是同一个指针。

package main

import (
	"context"
	"errors"
	"fmt"
	"net"
	"net/http"
	"sync/atomic"
)

var errStopped = errors.New("示例主动停止拨号")

type dialStats struct {
	attempts atomic.Int64
}

func main() {
	stats := &dialStats{}
	base := http.DefaultTransport.(*http.Transport).Clone()

	base.DialContext = func(context.Context, string, string) (net.Conn, error) {
		// 闭包捕获同一个 stats 指针，不执行真实网络连接。
		stats.attempts.Add(1)
		return nil, errStopped
	}

	cloned := base.Clone()

	// 两个 Transport 实例不同，但回调访问同一份计数器。
	_, _ = base.DialContext(context.Background(), "tcp", "example.invalid:80")
	_, _ = cloned.DialContext(context.Background(), "tcp", "example.invalid:80")
	fmt.Println(base != cloned)        // true：Transport 对象独立
	fmt.Println(stats.attempts.Load()) // 2：闭包状态仍然共享
}

这不是 Clone 偷懒复制了内部连接池，而是 Go 函数值本身没有“深拷贝闭包环境”的通用操作。同样的判断适用于 Proxy、OnProxyConnectResponse、GetProxyConnectHeader、DialTLSContext 等函数字段：如果回调捕获了缓存、计数器、令牌或租户配置，它们是否隔离要由调用方决定。

逐字段看 Clone：新容器不等于内部对象全新

TLSClientConfig：外层独立，内部引用仍要检查

Transport.Clone 会对非空的 TLSClientConfig 调用 tls.Config.Clone，所以两个 Transport 不会持有同一个 *tls.Config 指针。问题在下一层：官方明确把 tls.Config.Clone 定义为浅拷贝。函数回调、接口实现以及部分切片或映射指向的对象，不会自动变成全新的业务对象。

客户端最容易忽略的是 ClientSessionCache。它是接口字段，浅拷贝后通常仍指向同一个缓存实现。下面的比较直接展示“配置指针不同、缓存对象相同”：

package main

import (
	"crypto/tls"
	"fmt"
	"net/http"
)

func main() {
	cache := tls.NewLRUClientSessionCache(64)
	base := http.DefaultTransport.(*http.Transport).Clone()
	base.TLSClientConfig = &tls.Config{
		// 显式放入可复用的客户端会话缓存。
		ClientSessionCache: cache,
	}

	cloned := base.Clone()

	// 外层 tls.Config 是副本，但接口仍可指向同一个缓存实现。
	fmt.Println(base.TLSClientConfig != cloned.TLSClientConfig)
	fmt.Println(base.TLSClientConfig.ClientSessionCache == cloned.TLSClientConfig.ClientSessionCache)
}

共享会话缓存不一定是错误。它可能提高同一安全域中的 TLS 恢复命中率；但如果两个 Transport 属于不同租户、不同测试用例或不同密钥生命周期，就应该显式创建独立缓存。判断标准不是“看到共享就全部拆开”，而是先定义需要隔离的边界。

TLSNextProto：映射独立，函数语义仍可能共享

TLSNextProto 的外层 map 会重新创建，因此给克隆后的 map 增删协议键，不会直接改到原 map。但 map 的值是函数，函数值复制后仍可能带着同一个闭包环境。于是“容器已经隔离”和“容器中的行为没有共享状态”是两个不同问题。

package main

import (
	"crypto/tls"
	"net/http"
	"sync/atomic"
)

func attachProtocol(t *http.Transport, hits *atomic.Int64) {
	t.TLSNextProto = map[string]func(string, *tls.Conn) http.RoundTripper{
		"demo": func(string, *tls.Conn) http.RoundTripper {
			// map 可以被克隆，闭包捕获的 hits 指针仍然相同。
			hits.Add(1)
			return http.DefaultTransport
		},
	}
}

排查这类问题时，不要只看第一层字段类型。沿着“字段值 → 函数闭包或接口实现 → 可变对象”继续追踪，才能找到真正的共享点。

需要强隔离时，重新构造外部依赖

如果业务要求每个 Transport 拥有独立拨号统计、独立 TLS 会话缓存和独立回调状态，可靠做法是在 Clone 后主动替换这些字段。下面把构造回调封装成工厂，每次调用都分配新的统计对象：

package transportx

import (
	"context"
	"crypto/tls"
	"net"
	"net/http"
	"sync/atomic"
	"time"
)

type DialStats struct {
	Attempts atomic.Int64
}

func newDialContext() (func(context.Context, string, string) (net.Conn, error), *DialStats) {
	stats := &DialStats{}
	dialer := &net.Dialer{Timeout: 3 * time.Second}

	return func(ctx context.Context, network, address string) (net.Conn, error) {
		// 每次工厂调用都捕获一份新的统计对象。
		stats.Attempts.Add(1)
		return dialer.DialContext(ctx, network, address)
	}, stats
}

func IsolatedClone(base *http.Transport) (*http.Transport, *DialStats) {
	cloned := base.Clone()

	// 替换回调，切断原闭包捕获状态。
	cloned.DialContext, stats := newDialContext()

	if cloned.TLSClientConfig == nil {
		cloned.TLSClientConfig = &tls.Config{}
	}
	// 替换接口实现，避免继续复用原会话缓存。
	cloned.TLSClientConfig.ClientSessionCache = tls.NewLRUClientSessionCache(64)

	return cloned, stats
}

若回调绑定在某个指针接收者方法上，也要检查接收者是否带可变状态。仅把方法值重新赋给另一个字段，仍可能绑定同一个接收者；真正隔离需要创建新的接收者实例。

什么时候应该 Clone，什么时候应该从零构造

Clone 适合“绝大多数网络配置一致，只调整少量字段”的场景，例如基于默认 Transport 修改代理、超时、TLS 根证书或连接上限。它可以避免手工漏掉新版本新增的导出字段，同时确保新实例不继承旧连接池。

如果隔离规则非常严格，而且配置里塞了许多带状态的闭包、接口和自定义对象，从零构造一个小而明确的 Transport 往往更容易审计。无论选哪种方式，都应把“共享哪些对象”写成设计决策，而不是把 Clone 当作任意对象图的深复制工具。

排查清单

1. 先确认观察到的是外部计数、缓存或回调状态，而不是误判为共享连接池。
2. 检查 DialContext、Proxy、DialTLSContext 等函数是否捕获指针。
3. 检查方法值绑定的接收者是否在多个 Transport 之间复用。
4. 检查 TLSClientConfig 中的回调、接口、切片和映射是否需要业务级深拷贝。
5. 不同安全域需要独立会话时，替换 ClientSessionCache。
6. 自定义 TLSNextProto 时，同时检查 map 和函数闭包两层。
7. Clone 后再修改配置，避免 Transport 已开始使用后并发修改字段。
8. 需要关闭连接时分别调用两个 Transport 的 CloseIdleConnections。

常见问题

Clone 后改超时会影响原 Transport 吗？不会。超时是按值复制的标量字段。

Clone 后能复用原来的空闲连接吗？不能。新实例有自己的连接池，需要重新建立连接。

共享 ClientSessionCache 就一定不安全吗？不一定，要看两边是否属于同一安全域以及是否允许复用 TLS 会话状态。跨租户或强隔离测试通常应拆开。

为什么文档说复制导出字段，仍然有共享？因为某些导出字段本身就是函数、接口或包含引用的配置。字段被复制，不代表字段所能到达的任意外部对象都能自动递归复制。

小结：http.Transport.Clone 的正确心智模型是“复制可配置字段，重置 Transport 自身运行时状态”。连接池和锁是独立的；闭包捕获对象、接口实现及浅拷贝配置内部引用是否独立，则取决于调用方。先划清需要隔离的边界，再主动替换对应依赖，才能既保留 Clone 的便利，也避免隐蔽的跨实例共享。