Go httptrace 怎样识别连接复用还是新建

识别 Go HTTP 请求是否复用连接，优先看 httptrace.ClientTrace.GotConn 收到的 GotConnInfo.Reused。值为 true 表示取得的连接此前已用于其他 HTTP 请求；false 表示这次取得的是尚未用于其他请求的连接。不要单凭有没有 DNS、拨号或 TLS 日志下结论。

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

先确定要回答哪一个连接问题

排查这类问题时，我会先把“是否复用”和“是否从空闲池取得”分开。前者回答连接历史，后者回答取得方式。把两者混成一个指标，容易在 HTTP/2 或并发场景里误报。

我建议诊断日志始终同时保存 Reused 与 WasIdle；仅当 WasIdle 为 true 时解释 IdleTime。连接复用也不代表 HTTP 状态码正常，响应状态与网络连接是两个维度。

用共享 Transport 建立最小观察入口

下面的完整示例对传入地址发起两次顺序 GET。它适合自有测试端点，响应应当有限且较小。示例不预设第二次一定复用，也不把未执行的示例当作运行结果。程序直接在回调中记录日志，避免用未经同步的共享布尔变量收集结果。

package main

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

func observe(client *http.Client, target string, id int) error {
    req, err := http.NewRequest(http.MethodGet, target, nil)
    if err != nil { return err }
    // 每次调用保留独立编号；日志函数支持多个回调并发写入。
    trace := &httptrace.ClientTrace{
        GotConn: func(info httptrace.GotConnInfo) {
            idle := "不适用"
            if info.WasIdle { idle = info.IdleTime.String() }
            log.Printf("请求=%d reused=%t wasIdle=%t idleTime=%s",
                id, info.Reused, info.WasIdle, idle)
            // Conn 属于 Transport，不在这里读、写或关闭。
        },
        ConnectStart: func(network, addr string) {
            log.Printf("请求=%d 开始拨号 network=%s", id, network)
        },
    }
    req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
    resp, err := client.Do(req)
    if err != nil { return fmt.Errorf("请求%d: %w", id, err) }
    // 仅观察受控的小响应：最多读取 1MiB 加一字节，避免无限排空。
    const limit = 1  limit { return fmt.Errorf("响应超过观察上限，不能保证读至EOF") }
    return nil
}

func main() {
    if len(os.Args) != 2 { log.Fatal("请提供一个受控的小响应 URL") }
    // 整个观察过程共享连接池；退出时关闭空闲连接。
    transport := http.DefaultTransport.(*http.Transport).Clone()
    defer transport.CloseIdleConnections()
    client := &http.Client{
        Transport: transport,
        Timeout: 10 * time.Second,
        // 不自动跟随重定向，便于观察单个请求跳转段。
        CheckRedirect: func(req *http.Request, via []*http.Request) error {
            return http.ErrUseLastResponse
        },
    }
    for id := 1; id 

把代码保存为 main.go，执行时传入你控制的测试 URL。示例故意不自动跟随重定向：默认客户端可能把一次 Do 扩展成多个请求跳转段，httptrace 本身没有覆盖整条重定向链的汇总钩子。

共享 Transport 是观察连接池的前提。每次请求都新建一个 Transport 会把池拆散，得到的“总是新连接”很可能是观察方式造成的。Client 超时限制了整个请求过程；读体也可能因超时而失败，这时不能宣称响应已完整消费。

怎样解释两次请求的观察记录

若第一条 GotConn 记录为 Reused=false，它说明取得的连接此前未服务其他请求；若第二条为 true，说明第二次取得了用过的连接。这仍不能证明它就是第一条请求那根连接，并发任务可能共享这个 Transport。需要精确关联时，应在受控诊断范围为连接建立独立标识，而不是把地址相同当成连接相同。

若第二条仍为 false，先看响应体是否完整消费、服务端是否关闭连接、是否超过空闲超时，以及目标、代理和 Transport 是否一致。响应超过示例上限时，读取会提前停止，程序明确报错；此时不保证连接可复用。不要为了提高复用比例无限读取未知大响应。

GetConn 在有缓存空闲连接时也会触发，不能计入“新建连接数”。ConnectStart 可能因双栈拨号出现多次，也不能与请求数直接一一相减。GotConn 只在成功取得连接后调用；取连接失败应查看 Do 返回的错误，而不是等待一个不存在的 GotConn 失败回调。

HTTP/2 与并发回调带来的边界

HTTP/2 可在已有连接上并发承载多个流，因此复用连接并不等于从空闲池领出独占连接。遇到 Reused=true、WasIdle=false 时，不应仅据此判定池异常。结合 resp.Proto 记录协议，再解释字段更稳妥。

PutIdleConn 当前不用于 HTTP/2，关闭长连接复用时也不会调用。缺少这个事件不等于连接泄漏。回调可能从不同 goroutine 并发执行，部分还可能在请求完成或失败后出现；线上异步收集器需要同步保护与明确的事件接收生命周期，不能在 Do 返回后立即关闭仍可能被回调写入的通道。

线上选择：先采样字段，再扩大事件范围

对我来说，常态采样的起点是请求编号、GotConn 两个布尔字段、协议和请求结果；只有要拆解握手成本时才追加 DNS、拨号和 TLS 事件。这样日志量和回调开销更可控。请求编号应避免包含用户标识，URL 查询串与完整网络地址也不应默认进入普通日志。

• 复用比例的分母限定为已触发 GotConn 的观察事件，另行统计取连接失败；不要把它冒充所有业务调用的成功率。
• 区分协议与目标维度，再比较趋势；代理场景中的连接目标未必等于业务 URL 主机。
• 重试可能产生多次相关事件；定义按事件、尝试还是业务调用聚合，避免用一次 Do 固定对应一条连接记录。
• 保留连接所有权：GotConnInfo.Conn 仍归 Transport 管理，禁止借诊断之名读取、写入或关闭它。

常见疑问：IdleTime 为零能说明新建吗？不能，先看 WasIdle 与 Reused。第二次为什么不保证复用？连接可用性还取决于协议、响应消费、服务端关闭和池配置。只想知道是否复用需要全部钩子吗？通常只添加 GotConn 就足够，其他钩子用于解释原因。

相关连接池与响应体规则可查官方文档：https://pkg.go.dev/net/http。