Go net/http.Transport 结果不稳定怎么办

net/http.Transport 的请求结果不稳定时，先把问题分成连接或协议错误、HTTP 状态变化、正文内容变化三类，再固定请求输入和客户端配置。长期复用 Transport、正确处理响应体，并记录连接复用线索，比每次重建客户端或直接增加重试更有助于找到差异来源。

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

先把不稳定分成三类现象

“同一个接口有时正常、有时报错”还不是足够精确的问题描述。应先保存触发命令对应的请求方法、业务参数、状态码与完整错误类型，并明确失败发生在 Do 返回时，还是读取响应体时。不要把敏感请求头、令牌或完整私人 URL 直接写入诊断日志。

成功收到非 2xx 响应不一定让 Client.Do 返回错误，因此只检查 err 会把上游拒绝、限额或业务错误混成“成功”。同样，收到响应头不等于正文已经完整到达。分类以后，才有办法确认问题到底属于哪一层。

为什么常见修复会掩盖问题

每次新建 Transport。这样会不断丢失复用已有连接的机会，把连接建立成本和旧连接行为一起改变。若错误暂时减少，仍不能据此证明“连接池不安全”。先确认应用是否在合理范围复用同一 Transport，以及初始化后是否还有代码修改共享配置。

只关闭正文，不关心有没有读完。HTTP/1.x 的连接复用与响应体是否读到结束、是否关闭有关。不同版本的实现可能在关闭时尝试有限度的异步读取，但不应依赖它替业务完成任意大正文。正常有界响应应按协议处理完整；超大或流式响应需要自己的消费与停止策略。

直接关闭 keep-alive。它可以成为隔离变量的临时对照，却同时改变请求成本与连接行为。正式修复仍需解释：是否上游关闭了空闲连接、是否响应体处理不完整，或者是否有网络中间层差异。不要一次改动协议、超时、代理和连接复用，最后只留下“改完好了”。

所有错误都重试。Transport 对部分满足条件的请求有自身重试行为，但它不是任意业务操作的重试保证。没有服务端去重语义时，给写请求加个键也不会自动让业务变得幂等。应先判断错误是否允许重试、请求体能否重建，以及上游操作是否可能已经完成。

固定Transport与响应体的使用方式

在应用初始化阶段构造专用 Transport，保持使用期间配置稳定；请求拥有各自的 Request 与上下文。调用方负责在成功取得响应后关闭 Body，不要在一个长循环里积累大量 defer，宜把单次请求拆到独立函数。

// 初始化阶段创建一次，后续请求复用；数值只是示例预算
base := http.DefaultTransport.(*http.Transport)
tr := base.Clone()
client := &http.Client{
    Transport: tr,
    Timeout: 10 * time.Second,
}
// 应用结束或专用池退出使用时清理空闲连接
defer tr.CloseIdleConnections()

若应用替换了全局 DefaultTransport，上面的类型断言可能不适用，应使用自己明确持有的 *http.Transport 模板。这里的 defer 应位于真正拥有客户端生命周期的作用域，不能放在刚构造完客户端就返回的辅助函数中。

比较两次调用时还要固定代理配置、目标地址、请求头和请求体，区分 Client 的重定向或 Cookie 策略与 Transport 的连接行为。某个 Client 包装器增加了鉴权、签名或重试，也应纳入记录，不能只看最底层连接池。

怎样记录连接复用线索

httptrace 可以记录获取连接和收到首个响应字节等事件。以下为原创的有界 GET 诊断函数，传入稳定的客户端和不含秘密的请求标识。函数只记录事件，不输出正文或完整 URL；返回的状态、协议和读取内容由调用方按业务规则比较。

package transportdiag

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

type Result struct {
    Status int
    Proto  string
    Body   []byte
}

// ObserveGET 适用于有限大小响应；不在函数内增加业务重试
func ObserveGET(ctx context.Context, client *http.Client, address, id string) (out Result, retErr error) {
    start := time.Now()
    trace := &httptrace.ClientTrace{
        GotConn: func(info httptrace.GotConnInfo) {
            // 使用并发安全的日志器，不共享写入普通切片或计数器
            log.Printf("id=%q got_conn reused=%t idle=%t elapsed=%s",
                id, info.Reused, info.WasIdle, time.Since(start))
        },
        GotFirstResponseByte: func() {
            log.Printf("id=%q first_byte elapsed=%s", id, time.Since(start))
        },
    }
    traced := httptrace.WithClientTrace(ctx, trace)
    req, err := http.NewRequestWithContext(traced, http.MethodGet, address, nil)
    if err != nil {
        return out, fmt.Errorf("创建请求: %w", err)
    }
    resp, err := client.Do(req)
    if err != nil {
        return out, fmt.Errorf("发送请求: %w", err)
    }
    // 关闭错误与读取错误一起返回，避免覆盖已有原因
    defer func() { retErr = errors.Join(retErr, resp.Body.Close()) }()
    out.Status, out.Proto = resp.StatusCode, resp.Proto

    const maxBody = 1  maxBody {
        return out, fmt.Errorf("响应正文超过诊断上限")
    }
    out.Body = data
    return out, nil // 状态码由调用方判断，不与传输错误混淆
}

示例需要支持 errors.Join 的 Go 工具链。函数不会自动把非 2xx 视为传输错误，调用方应检查 Result.Status，并按接口的稳定字段比较正文。若响应超限，函数停止读取并关闭；这时没有完整消费正文，不能承诺相应连接仍可复用。不要为了复用而无限读取未知大小的数据。

Trace 钩子可能并发调用，部分事件还可能在请求完成或失败后到达。使用独立请求标识关联事件，不要假定函数返回就是日志事件的绝对终点。GotConn.Reused 为 true 仅表示连接此前被使用过，不表示这次响应内容来自本地缓存，也不意味着已经找到错误原因。

哪些边界会改变判断

自动重定向：一次 Client.Do 可能涉及多个请求，最终协议和状态不一定来自最初地址。httptrace 的单轮事件不是完整重定向链记录。排查时应明确是否允许跳转，并分别保留业务上允许记录的跳转标识。

协议不同：HTTP/1.x 与 HTTP/2 的复用机制不同，不能把某条 HTTP/1.x 经验直接当成 HTTP/2 的全部行为。先记录实际响应协议，再围绕对应协议判断；本文不把某个连接参数当成通用修复。

截止时间：连接等待、响应头等待、正文读取分别可能消耗时间。全链路超时和局部超时的作用范围不同；无限加大超时可能只是把错误变成长时间积压。先记录在哪个阶段耗尽预算，再调整相应约束。

服务端数据本来会变：负载均衡后端版本、缓存、时间相关字段和请求参数差异，都可能改变正文。连接复用与结果变化同时出现，只是相关线索。需要固定这些输入或利用服务端请求记录进一步解释。

相关问题与排查记录

CloseIdleConnections 能中止当前慢请求吗？不能，它清理的是空闲连接。取消当前请求应通过请求上下文等适用机制处理。

复用 Transport 会导致多个 Request 混在一起吗？Transport 支持并发使用，但每次请求仍应有独立、正确管理的 Request 和 Body。共享可变请求头、正文读取器或业务缓冲区会引入另一类问题。

日志有 Reused 就能认定旧连接坏了吗？不能。还需结合错误、请求阶段和上游记录。对照时一次只调整一个变量，保留变化前后的原始观察。

最有用的排查记录应包含：请求标识、输入版本、Transport 配置版本、协议、复用标记、状态码、Do 错误与读取错误，以及是否完整消费正文。本文代码未在读者环境执行，没有虚构延迟或错误率。Trace 文档入口：https://pkg.go.dev/net/http/httptrace#ClientTrace。