Go net/http.Transport 升级后行为变化怎么定位

Go 版本或 HTTP 客户端依赖升级后，如果发现请求延迟、连接数、代理行为或连接复用状态变了，先不要把问题归结为“Transport 被升级改坏了”。更稳妥的做法是把客户端缩成一个小实验：固定 Transport，记录 httptrace.GotConnInfo，确认响应体是否正确结束，再逐项恢复业务配置。

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

本文要得到的结果：能区分“连接根本没有复用”“复用条件被业务代码破坏”“显式连接池参数改变”和“服务端或代理行为变化”这四类现象。

先固定一个最小 Transport 配置

第一步不要直接在完整业务服务里改参数。把请求地址、客户端超时和 Transport 放到一个小函数中，先让每次实验都使用同一套输入。自定义 Transport 时，通常应从默认 Transport 克隆，而不是把全局对象当成共享配置随意修改。

package main

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

func main() {
    // 从默认实现复制一份，避免实验代码改变进程中其他请求的共享状态。
    transport := http.DefaultTransport.(*http.Transport).Clone()
    transport.MaxIdleConnsPerHost = 8
    transport.IdleConnTimeout = 30 * time.Second

    // 客户端超时和连接池参数分开设置，便于定位到底是哪一层发生变化。
    client := &http.Client{
        Transport: transport,
        Timeout:   5 * time.Second,
    }

    request, err := http.NewRequestWithContext(
        context.Background(), http.MethodGet, "https://example.com/health", nil,
    )
    if err != nil {
        // 构造请求失败时直接退出，避免把无效请求误判成连接问题。
        panic(err)
    }

    trace := &httptrace.ClientTrace{
        GotConn: func(info httptrace.GotConnInfo) {
            // Reused 说明连接被复用，WasIdle 可辅助判断它是否来自空闲池。
            fmt.Printf("reused=%v wasIdle=%v idle=%s\\n", info.Reused, info.WasIdle, info.IdleTime)
        },
    }
    request = request.WithContext(httptrace.WithClientTrace(request.Context(), trace))

    response, err := client.Do(request)
    if err != nil {
        // 网络错误、超时和服务端响应错误要先分开记录。
        panic(err)
    }
    // 读尽响应体并关闭它，给 HTTP/1.x 连接复用留下必要条件。
    _, copyErr := io.Copy(io.Discard, response.Body)
    closeErr := response.Body.Close()
    if copyErr != nil || closeErr != nil {
        // 这里保留两个错误，避免把响应体生命周期问题吞掉。
        panic(fmt.Errorf("body copy: %v, body close: %v", copyErr, closeErr))
    }
}

这个最小程序的重点不是请求某个固定站点，而是让实验变量变少。正式排查时，把地址替换为你自己的测试服务，并保留同一个 URL、请求方法、请求头和响应体大小。

用 httptrace 看变化发生在哪一层

仅看总耗时很难判断问题。httptrace.ClientTrace 的 GotConn 回调可以记录连接是否复用。两次请求都使用同一个 Transport 时，如果升级前经常出现 Reused=true，升级后持续为 false，就说明应该继续检查连接池、响应体和代理/TLS，而不是先调整业务重试次数。

建议至少记录下面三个字段：

为了避免一次采样误导判断，可以连续发送两次相同请求：第一次记录建连路径，第二次观察是否回到连接池。若第二次也不复用，再进入下一节检查响应体；若只在长时间间隔后不复用，则要对照 IdleConnTimeout 和服务端 keep-alive 策略。

检查 Response.Body 的关闭与读尽

这是排查“升级后连接数变多”时最容易漏掉的一项。对于 HTTP/1.x，响应体没有读到结束位置就直接返回，或者根本没有关闭 Response.Body，都可能让连接失去复用机会。升级后如果响应体更大、错误分支更多，原来隐藏的问题可能会更频繁出现。

业务代码不要只在成功分支关闭响应体，推荐把生命周期放在拿到响应后立刻处理：

func readHealth(client *http.Client, url string) error {
    // 每次拿到响应后马上登记关闭动作，覆盖后续解析失败的分支。
    response, err := client.Get(url)
    if err != nil {
        return err
    }
    defer response.Body.Close()

    // 读到 EOF，避免 HTTP/1.x 因未消费完响应体而放弃连接复用。
    body, err := io.ReadAll(response.Body)
    if err != nil {
        return err
    }
    if response.StatusCode = 300 {
        // 非 2xx 也要先结束响应体，再把状态码交给上层决定是否重试。
        return fmt.Errorf("unexpected status %s: %s", response.Status, string(body))
    }
    return nil
}

这里的“读尽”不是要求把响应内容永久保存在内存里。大响应可以流式写入文件或解码器，只要业务明确消费策略，并在结束时关闭响应体。若业务确实要提前停止读取，应把“不复用这条连接”当成可接受的代价，而不是把它和 Transport 参数问题混在一起。

逐项对比 Transport 的显式配置

当响应体生命周期没有问题后，再对比 Transport 中真正会影响连接行为的字段。不要一次改五个参数，否则即使现象恢复，也无法知道是哪一项起作用。

如果 Transport 来自第三方库，先找它是否创建了新的客户端或覆盖了默认 Transport。常见误判是：业务层以为自己复用了一个客户端，库内部却每次请求都创建新客户端；这种情况下，版本升级只是改变了问题出现的概率。

用三组结果判断升级影响范围

最后把同一测试拆成三组：旧 Go 版本加旧配置、新 Go 版本加旧配置、新 Go 版本加显式配置。每组都记录请求次数、Reused 比例、错误类型、请求间隔和响应体处理方式。

可以用下面的判断表收敛范围：

这样得到的结论应该是“在某个输入和配置组合下，复用状态发生变化”，而不是“升级后 Transport 一定有问题”。如果最终确认是版本行为差异，再去对应版本的 Go 发布说明或 issue 查具体变更；在证据出现前，不要用版本号替代定位。

常见追问

为什么只设置 Timeout 不能解决连接数变多？

http.Client.Timeout 控制一次请求的总时间，不负责决定空闲连接池容量，也不能替代响应体关闭。连接数问题要回到 Transport 和 Response.Body 生命周期。

每次请求都创建 Transport 会怎样？

通常会失去跨请求的连接池复用，还可能造成更多握手和临时连接。需要共享连接时，应复用同一个 Client/Transport，并在程序生命周期内保持其配置稳定。

看到 Reused=false 就一定是升级回归吗？

不是。首次请求、空闲超时、服务端关闭、代理切换、请求体或响应体处理方式变化，都可能让它为 false。只有在输入、间隔和配置可比时，旧版与新版的差异才有诊断价值。