Go httptrace.GetConn 怎样记录客户端选择的目标地址

如果 Go HTTP 客户端需要回答“这次请求准备连到哪里”，可以在请求上下文中安装 httptrace.ClientTrace，让 GetConn 回调记录 Transport 交给连接阶段的 host:port。它适合确认目标主机、代理入口或请求是否走到了预期的连接路径，但不代表连接已经建立，更不代表连接一定复用成功。

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

最稳妥的判断链是：GetConn 记录“准备连接的目标”，GotConn 记录“已经取得连接”，RoundTrip 或 Client.Do 的错误记录“这次请求最终是否失败”。不要只看到一条 GetConn 日志就下结论。

• GetConn：收到一次准备创建连接或从空闲池取连接的通知，并拿到 host:port。
• GotConn：连接取得成功，可以继续看 GotConnInfo.Reused 等结果。
• 请求错误：连接取得失败没有专门的 GetConn 失败回调，要看 Transport.RoundTrip 返回的错误。

先区分 GetConn 记录的是什么

GetConn 在连接创建前或从 Transport 的 idle pool 取连接前触发。官方定义中的参数是目标或代理的 host:port，即使已有空闲连接，它也可能照常触发。因此它回答的是“连接阶段准备处理哪个地址”，不是“最终 TCP 连接的远端地址已经确认”。

这一区分很重要：如果程序配置了 HTTP 代理，回调里看到的地址可能是代理入口；如果请求没有代理，通常才更接近目标服务的地址。要确认是否拿到了连接，应把同一个 trace 的 GotConn 一起记录。

把 GetConn 绑定到一条请求

使用 httptrace.WithClientTrace 生成带 trace 的上下文，再通过 http.NewRequestWithContext 把它交给客户端。下面的示例只记录当前请求的目标地址和阶段耗时，避免把全局变量当成并发安全的请求日志容器。

package main

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

func requestWithTargetTrace(ctx context.Context, client *http.Client, url string) error {
	start := time.Now()
	trace := &httptrace.ClientTrace{
		GetConn: func(hostPort string) {
			// 这里记录的是连接阶段准备处理的目标或代理地址。
			fmt.Printf("get-conn target=%s elapsed=%s\n", hostPort, time.Since(start))
		},
	}

	traceCtx := httptrace.WithClientTrace(ctx, trace)
	req, err := http.NewRequestWithContext(traceCtx, http.MethodGet, url, nil)
	if err != nil {
		// URL 解析失败时请求还没有进入 Transport，直接返回原因。
		return fmt.Errorf("创建请求失败: %w", err)
	}

	resp, err := client.Do(req)
	if err != nil {
		// GetConn 可能已经打印过，但这不表示本次请求最终成功。
		return fmt.Errorf("发送请求失败: %w", err)
	}
	defer resp.Body.Close()
	return nil
}

示例中的 GetConn 闭包只接收本次回调的字符串并写日志，不把地址放进共享切片，所以多个请求并发时不会因为普通 map 或 slice 的无锁写入产生额外竞态。真正的业务日志可以换成带 request ID 的结构化记录。

用 GotConn 补上“是否真的拿到连接”

排查时常见的误判是：看到 GetConn 就认为连接池已经命中。正确做法是同时监听 GotConn，让日志形成“准备目标 → 获得连接 → 请求结果”的链路。GotConnInfo 可以提供复用状态；如果没有成功取得连接，最终仍要从请求错误判断。

func requestWithConnectionTrace(ctx context.Context, client *http.Client, url string) error {
	trace := &httptrace.ClientTrace{
		GetConn: func(hostPort string) {
			// 这一步只说明 Transport 开始处理这个目标地址。
			fmt.Printf("target=%s\n", hostPort)
		},
		GotConn: func(info httptrace.GotConnInfo) {
			// Reused=true 才说明本次取得的连接来自复用路径。
			fmt.Printf("connected reused=%t was-idle=%t idle-time=%s\n",
				info.Reused, info.WasIdle, info.IdleTime)
		},
	}

	traceCtx := httptrace.WithClientTrace(ctx, trace)
	req, err := http.NewRequestWithContext(traceCtx, http.MethodGet, url, nil)
	if err != nil {
		return fmt.Errorf("创建请求失败: %w", err)
	}
	resp, err := client.Do(req)
	if err != nil {
		// 没有独立的“取得连接失败”回调，这里保留 Transport 的原始错误。
		return fmt.Errorf("请求未完成: %w", err)
	}
	defer resp.Body.Close()
	return nil
}

这三类信息的含义可以这样读：

代理、并发和清理时最容易踩的坑

看到的是代理地址怎么办？

先检查 Transport 的代理配置。GetConn 的参数定义允许它表示目标或代理，因此代理开启时不要把这条日志直接当成服务端最终地址。若需要业务侧目标 URL，应同时记录请求的 req.URL，把“请求目标”和“连接入口”分成两个字段。

回调会不会阻塞请求？

会。回调本身运行在请求链路中，复杂的格式化、网络上报或加锁都可能放大延迟。生产环境建议只采集必要字段，交给已有的异步日志管道；不要在 GetConn 内再次发起 HTTP 请求。

多个请求共用一个 trace 可以吗？

不建议把带状态的 trace 闭包跨请求复用。官方说明 ClientTrace 的回调可能并发执行，而且一个 trace 主要描述单次请求与响应。通常按请求创建 trace，把 request ID 放进闭包或上下文即可。

为什么还要关闭 Response.Body？

httptrace 只负责观测，不会接管响应体生命周期。成功拿到响应后仍由调用方读取并关闭 Body，否则连接复用和资源回收会受到影响。GetConn 的日志也不能代替这一清理责任。

相关问题

GetConn 回调能判断 DNS 是否发生吗？

不能。它只表示连接阶段准备处理哪个地址。若要观察 DNS 阶段，应另外配置 DNSStart 和 DNSDone，不要把 GetConn 的时间差解释成 DNS 耗时。

GetConn 触发了，为什么 GotConn 没有触发？

说明连接没有成功取得，或请求在更早阶段被取消。具体原因应以 client.Do 返回的错误为准，并结合超时、代理和 Transport 日志继续排查。

怎样确认连接池是否复用？

使用 GotConn 的 Reused 字段，并确保客户端和 Transport 的生命周期足够长；不要只看 GetConn 是否被调用，因为有空闲连接时 GetConn 也可能触发。