Go Transport 修改后为什么请求仍使用旧配置

Go Transport 修改后请求看起来仍使用旧配置，常见原因有两类：请求实际还在使用旧 Client 或旧 Transport；或者请求复用了已有连接，没有重新执行拨号或 TLS 握手。不要在并发请求期间直接改 Transport 字段。更稳妥的做法是构建一代新客户端，配置完成后切换入口，再让旧代请求结束并回收闲置连接。

官方文档入口：https://pkg.go.dev/net/http。下面只讨论标准 http.Transport，不把第三方 RoundTripper 的行为混为一谈。

我会先查实例归属，再看某个超时数字

设计 HTTP 客户端配置更新时，我更愿意给实例加一个配置代号，而不是只打印“配置文件已刷新”。这能区分文件读取成功、实例构造成功和请求入口已经切换三个不同事实。本文用顺序示例表达这种取舍，不把它描述为亲历线上事故或已执行实验。

例如局部变量 tr 已经换成新对象，但业务结构体还保存 oldClient；又或者两个 Client 共用了同一个旧 Transport。此时继续调整新对象的字段，当然不会改变旧实例发出的请求。Client.Transport 为 nil 时使用默认 Transport，也不能据此认为它会自动指向你另外创建的对象。

我最不想省掉的区分：请求不一定新建连接

Transport 会管理连接复用。DialContext 用在建立连接时；已经有合适连接时，请求不一定触发拨号。TLS 相关建立阶段参数也不会让已完成的握手重新发生。因此，用“下一次请求没有触发新拨号”证明配置切换失败，证据并不充分。

但不能反过来把所有字段都解释成“只对新连接生效”。拨号超时、响应头超时、闲置连接时长和整个 Client 超时作用于不同阶段。先确认你改的是哪个字段，再确认观察指标是否对应那个阶段；不能靠一个总耗时就判断所有配置的行为。

我倾向于配置完成后发布，而不是边用边修改

下面的 buildClient 从默认配置复制出独立 Transport，完成设置后不再改字段。main 只演示没有并发工作者的顺序交接：旧请求连同响应 Body 结束后，下一次调用明确使用新 Client。示例依赖读者自己控制的本机测试服务，本文没有运行它，也没有编造网络延迟结果。

package main

import (
    "fmt"
    "io"
    "net"
    "net/http"
    "time"
)

func buildClient(dialTimeout time.Duration) (*http.Client, *http.Transport, error) {
    if dialTimeout  maxBody {
        return fmt.Errorf("response exceeds size limit")
    }
    if resp.StatusCode = 300 {
        return fmt.Errorf("unexpected HTTP status: %d", resp.StatusCode)
    }
    return nil // 函数返回时 Body 已经关闭
}

func main() {
    oldClient, oldTransport, err := buildClient(2 * time.Second)
    if err != nil {
        fmt.Println(err)
        return
    }
    defer oldTransport.CloseIdleConnections() // 退出时再做一次闲置连接回收

    // 顺序演示：这里没有并发工作者持有旧实例
    if err := fetch(oldClient, "http://127.0.0.1:8081/health"); err != nil {
        fmt.Println(err)
        return
    }

    newClient, newTransport, err := buildClient(500 * time.Millisecond)
    if err != nil { // 新配置构造失败就不切换
        fmt.Println(err)
        return
    }
    defer newTransport.CloseIdleConnections()
    oldTransport.CloseIdleConnections() // 旧请求及 Body 已结束，之后不再使用旧实例

    if err := fetch(newClient, "http://127.0.0.1:8081/health"); err != nil {
        fmt.Println(err) // 请求失败不自动回放，避免隐藏业务重试语义
        return
    }
    fmt.Println("两代客户端的顺序请求均完成") // 不代表已经测量超时效果
}

这里的 Clone 是复制公开配置，不是把旧连接池搬到新 Transport。工厂中的默认对象类型断言也有前提：应用没有把 http.DefaultTransport 换成其他 RoundTripper。若项目已经替换默认传输器，应改用应用自己的已知配置模板，而不是保留可能 panic 的断言。

两个拨号预算只是演示值。访问健康的本机服务可能都立即成功，不能凭成功打印判断 500 毫秒的拨号超时已经被触发。超时差异应在独立受控场景结合连接事件观察，不能把生产请求强行变慢来做证明。

真正热切换时，入口和响应体都要算在交接里

我的取舍是：简单服务优先接受短暂停流，确认旧请求与响应体全部结束后再切换；确需不停流时，才引入代际管理。配置刷新者负责构造新代，统一入口负责选择代号，旧代只接收已分配给它的工作，资源管理者负责排空回收。

并发版本不能把上面 main 里的局部变量赋值照搬成共享变量写入。必须用锁或原子发布等同步手段保护入口，而且发布后所有字段保持不可变。仅原子替换一个指针还不够：其他工作者可能已经拿到旧指针，旧的响应 Body 也可能仍在被读取。

CloseIdleConnections 只针对闲置连接，不会中断正在使用的连接，更不是“立即切换所有请求”的按钮。旧代已经停止接单、已有工作及响应体结束后再回收，含义才清楚。若业务要求强制撤销旧连接上的请求，应另行设计取消策略及失败语义，不能依靠闲置连接关闭来实现。

我会把失败回退和诊断记录限制在明确边界

可以用 net/http/httptrace 的 GotConn 事件记录 Reused 等连接信息，再配合配置代号分析；不要记录认证头、代理密码或完整敏感 URL。trace 回调可能与其他执行并发，记录共享状态时也要同步。TLS、拨号和重定向还各有事件与边界，不能用一个回调覆盖全部情况。

构造失败时保留旧代，通常比发布半成品容易理解。但新代已经发送的请求失败后，自动切回旧代重发可能造成业务重复，尤其涉及写入操作。应由调用层明确是否允许重试、是否有幂等保护，配置更新层不应隐式决定。

哪些情况值得用代际方案

每次请求都新建 Transport 最简单吗？它会丢掉长期复用的收益。我会按配置变化创建一代，而不是按请求创建一代；如果配置从不变化，就长期复用同一个完成配置的实例。

只调 CloseIdleConnections 能解决吗？它能回收闲置连接，但不修复错误的实例归属，也不让并发字段写入变安全。

修改 TLS 配置就能让旧连接重新验证吗？已有连接不会因此重新握手。涉及证书信任或安全政策切换，应制定新连接、旧请求与取消行为的明确策略。

对我来说，这套方案的收益是配置更新有了可追踪的边界，代价是交接管理变复杂。单次初始化足够的程序不必引入完整热更新；需要热更新时，也应先把实例归属、发布同步、响应体排空与失败回退拆清楚，再谈“配置立即生效”。

参考：http.Transport、Transport.Clone、httptrace。