直接替换http.DefaultTransport会丢弃原连接池、TLS配置和超时策略，引发连接复用失效、超时异常及并发竞态；正确做法是新建http.Client并注入自定义RoundTripper，或安全拷贝默认Transport后包装。
为什么直接替换 http.DefaultTransport 会出问题
很多开发者一上来就写 http.DefaultTransport = &myRoundTripper{...}，结果发现全局 HTTP 请求（比如 http.Get、第三方库发起的请求）行为异常，甚至 panic。根本原因是 http.DefaultTransport 是一个已初始化的指针，直接赋值虽能覆盖，但原 transport 的连接池、TLS 配置、超时设置等状态被丢弃，且并发访问时可能引发竞态——http.Transport 内部字段（如 IdleConnTimeout、MaxIdleConns）不是线程安全的裸赋值目标。
正确做法是：新建一个 http.Client 实例，把自定义 RoundTripper 塞进它的 Transport 字段；或者，若必须复用默认 transport 的配置，应基于 http.DefaultTransport 类型做浅拷贝再修改：
tr := &http.Transport{}
*tr = *http.DefaultTransport.(*http.Transport) // 注意类型断言安全
tr.RoundTrip = myCustomRoundTripFunc // ❌ 错误：RoundTrip 是方法，不能赋值
// 正确：包装或嵌入
tr = &customTransport{Transport: tr}
如何安全地包装默认 Transport 实现日志/重试逻辑
最常见需求是加请求日志或失败重试，但又不想丢掉默认 transport 的连接复用、HTTP/2 支持、Keep-Alive 管理等能力。这时不该从头实现 RoundTripper，而应组合现有 http.Transport：
- 定义结构体嵌入
*http.Transport，重写RoundTrip方法，在调用原RoundTrip前后插入逻辑 - 注意：必须显式调用
t.Transport.RoundTrip(req)（假设字段名是Transport），不能直接调t.RoundTrip(req)，否则无限递归 - 对
req做修改（如加 header）前要req.Clone(req.Context())，否则可能污染原始请求对象 - 重试时需重新构造
*http.Request，因为Body通常不可重放（除非是bytes.Reader或明确支持Seek）
示例关键片段：
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
type loggingTransport struct {
Transport http.RoundTripper
}
func (t *loggingTransport) RoundTrip(req *http.Request) (*http.Response, error) {
start := time.Now()
resp, err := t.Transport.RoundTrip(req)
log.Printf("HTTP %s %s → %d (%v)", req.Method, req.URL,
resp.StatusCode, time.Since(start))
return resp, err
}
RoundTrip 方法里哪些错误必须透传，哪些可以拦截
Go 的 http.RoundTripper 合约要求：只要返回非 nil error，就必须保证返回的 *http.Response 为 nil；反之，若返回 resp，则 error 必须为 nil。违反这点会导致 http.Client panic 或静默失败。
需要特别注意的错误类型：
-
url.Error（如 DNS 解析失败、连接拒绝）：必须透传，这是客户端可识别的网络层错误 -
net/http.httpError（内部错误，如状态行解析失败）：透传，Client 会转为http.ProtocolError - 自定义业务错误（如 token 过期、限流响应）：不能在
RoundTrip中返回，应让响应正常返回，由上层Client.Do后检查resp.StatusCode处理 - 超时错误（
context.DeadlineExceeded）：若你在RoundTrip中主动 cancel context，必须确保不破坏原 transport 的 timeout 机制，否则可能让连接池卡死
使用 http.Transport 时容易忽略的连接池细节
即使你只是包装默认 transport，底层仍依赖 http.Transport 的连接池。几个高频踩坑点：
-
MaxIdleConns和MaxIdleConnsPerHost默认都是100，但若你高频创建新http.Client（每个带独立 transport），连接不会复用，很快耗尽文件描述符 -
IdleConnTimeout控制空闲连接存活时间，默认30s；若服务端主动断连早于该值，客户端下次复用会收到read: connection reset by peer，此时 transport 会自动重试一次（仅限 GET/HEAD） -
ForceAttemptHTTP2默认 true，但若后端不支持 HTTP/2，首次请求可能因 ALPN 协商失败降级，延迟增加；调试时可通过curl -v或 Wireshark 观察 - 如果 transport 被多个 goroutine 共享（推荐做法），切勿在
RoundTrip中修改其字段（如TLSClientConfig），那是非并发安全的
真正需要定制传输层时，别只盯着 RoundTripper 接口本身——它只是链条一环，背后是 transport 的连接管理、TLS 握手、代理逻辑、HTTP 状态机。多数场景下，包装比重写更稳，而共享 transport 比新建 client 更省。
