RoundTripper 是 http.RoundTripper 接口，负责将 http.Request 转为 http.Response；不能直接替换 http.DefaultTransport，而应包装或继承其配置以复用连接池、TLS 和超时策略，避免超时或复用失效。
RoundTripper 是什么，为什么不能直接改 http.DefaultTransport
它不是个工具函数，而是 http.RoundTripper 接口，负责把 *http.Request 变成 *http.Response。你改不了 http.DefaultTransport 的底层行为——它本身就是一个实现了该接口的结构体，但它的字段（比如 Transport.DialContext）是导出的，可以安全覆盖；而整个替换为自定义实现，才是控制传输层的关键路径。
常见错误现象：net/http: timeout awaiting response headers 或连接复用失效，往往是因为没透传原有 Transport 的配置（如 MaxIdleConns），直接 new 一个空 http.Transport 就用。
- 所有自定义 RoundTripper 必须显式复用或继承原
http.Transport的连接池、TLS 设置、超时策略 - 不要在
RoundTrip方法里做阻塞操作（如同步日志写磁盘），会卡住整个连接池 - 如果只是加 Header 或重试逻辑，优先考虑用中间件式 wrapper（包一层现有 Transport），而非从零实现
怎么写一个带请求日志和重试的 RoundTripper
核心是包装原有 http.Transport，而不是重写全部逻辑。重点在于：调用前修改 *http.Request，调用后检查错误并决定是否重试，同时确保 Request.Body 可重复读（否则第二次 RoundTrip 会失败）。
使用场景：调试第三方 API 调用、对幂等性接口自动重试、注入 trace-id。
立即学习“go语言免费学习笔记（深入）”；
- 用
io.NopCloser(bytes.NewReader(buf))替换req.Body实现可重放，前提是原始 Body 是可读的字节流（strings.Reader、bytes.Buffer等） - 重试时必须克隆
*http.Request（用req.Clone(req.Context())），否则并发下可能 panic - 别在重试逻辑里无限制循环——加
maxRetries和指数退避（time.Sleep(time.Second ） - 日志建议只打关键字段：
req.Method、req.URL.String()、resp.StatusCode、耗时，避免序列化整个 Body
自定义 TLS 配置时 RoundTripper 的坑
如果你通过 http.Transport.TLSClientConfig 自定义证书或跳过验证，注意：这个配置只在新建连接时生效；已有空闲连接不会重新握手。所以修改后要清空连接池，否则旧连接仍走默认 TLS 行为。
性能影响明显：每次新建 TLS 连接开销大，尤其在高并发短连接场景；而跳过验证（InsecureSkipVerify: true）会让整个 Transport 失去 HTTPS 安全保障，且无法按域名粒度控制。
- 清空连接池必须调用
transport.CloseIdleConnections()，不是设新TLSClientConfig就立刻生效 - 需要域名级证书控制？别动全局
TLSClientConfig，改用tls.Config.GetCertificate或GetClientCertificate回调 - 自签名证书要加进
tls.Config.RootCAs，不是只设InsecureSkipVerify——后者等于关掉证书校验，不推荐用于生产
RoundTripper 和 http.Client 的生命周期关系
http.Client 持有 RoundTripper 引用，但不管理其内存；如果你用了带状态的自定义 RoundTripper（比如含 sync.Pool 或内部缓存），必须自己控制它的启停，Client 不会帮你 Close 或 Reset。
容易被忽略的地方：多个 http.Client 共享同一个自定义 RoundTripper 实例时，其内部状态（如计数器、缓存 map）会被并发访问，必须加锁或用原子操作。
- 不要在
RoundTrip方法里启动 goroutine 后不回收（比如发异步监控日志却忘了 waitgroup 或 context cancel） - 如果 RoundTripper 内部用了
sync.Pool，记得在服务退出前调用Pool.New = nil并允许 GC 清理，否则可能泄漏 - 测试时别只测单次请求——要压测并发调用，看连接复用是否正常、goroutine 是否疯长、error 是否被正确透传
真正难的从来不是实现接口，而是让自定义行为和 Go HTTP 栈的连接复用、上下文取消、错误分类、Keep-Alive 等机制不打架。每加一行逻辑，都得想清楚它在连接池里活了多久、在哪个 goroutine 里跑、会不会挡住别人。
