Go httptrace.Got1xxResponse 怎样处理 1xx 响应回调

如果你想知道 Go HTTP 客户端收到过哪些临时响应，应该把 httptrace.ClientTrace.Got1xxResponse 挂到请求上下文。它会在最终的非 1xx 响应之前，为每个 1xx 信息响应提供状态码和响应头；Got100Continue 已配置时，收到 100 Continue 仍会触发这个回调。

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

Got1xxResponse 到底在什么时候触发

这个回调观察的是客户端一次请求—响应往返中的 1xx 信息响应。它不是最终响应的替代品，也不会把 1xx 变成一个可以直接读取正文的 *http.Response。真正的业务响应仍由 Client.Do 返回，回调只负责把临时响应头交给你的诊断或策略代码。

Go 官方定义的触发范围是：最终非 1xx 响应之前收到的每个 1xx 响应头。因为一个请求可能收到多个信息响应，所以回调不能写成“只进一次”的假设；如果要累计它们，应在请求级状态中保存记录。

把 ClientTrace 挂到请求上下文

注册点在请求上下文，而不是在全局客户端上。下面的示例只记录收到的状态码和 Link 响应头；生产代码可以把回调改成指标采集，但要避免在回调里做阻塞很久的工作。

package main

import (
	"fmt"
	"net/http"
	"net/http/httptrace"
	"net/textproto"
)

func main() {
	req, err := http.NewRequest(http.MethodGet, "https://example.com", nil)
	if err != nil {
		panic(err)
	}

	trace := &httptrace.ClientTrace{
		Got1xxResponse: func(code int, header textproto.MIMEHeader) error {
			// 回调只读取 1xx 的状态码和响应头，不把它当最终 Response。
			fmt.Printf("收到 1xx：%d，Link=%q\n", code, header.Get("Link"))
			// 返回 nil 表示继续等待最终的非 1xx 响应。
			return nil
		},
	}

	// 将追踪器放入请求上下文，范围只覆盖这一轮请求。
	req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))
	resp, err := http.DefaultClient.Do(req)
	if err != nil {
		panic(err)
	}
	// 最终响应体仍由调用方负责关闭，避免连接资源泄漏。
	defer resp.Body.Close()
	fmt.Println("最终状态：", resp.StatusCode)
}

如果上下文里已经有旧的 ClientTrace，WithClientTrace 会组合新的追踪钩子；当前新增的钩子会先被调用。这样可以在局部增加 1xx 观测，而不必覆盖调用链上已经存在的其它追踪逻辑。

回调参数和错误返回怎么处理

code 是 1xx 状态码，header 是 textproto.MIMEHeader。例如 103 Early Hints 常用于提前传递链接提示，100 Continue 则和客户端发送请求体前的确认有关。两者都可以用同一个回调接收，但业务含义不同，最好按状态码分支记录。

func onInformational(code int, header textproto.MIMEHeader) error {
	// 先保留状态码和关键头，便于把临时响应与最终响应关联起来。
	link := header.Get("Link")
	switch code {
	case 100:
		fmt.Println("服务端确认继续：", link)
	case 103:
		fmt.Println("收到 Early Hints：", link)
	default:
		fmt.Println("收到其它 1xx：", code)
	}
	// 只有明确不接受本次临时响应时才返回错误；正常观测应继续。
	return nil
}

回调返回非 nil 错误时，客户端会用这个错误中止本次请求。因此，记录日志、计数或提取 Link 后通常返回 nil；只有协议策略明确要求拒绝时，才返回业务错误。不要把“回调没有触发”直接等同于请求失败，服务端也可能没有发送 1xx。

并发、重定向和响应体边界别混在一起

ClientTrace 的钩子可能从不同 goroutine 并发调用，也可能在请求完成或失败后仍有回调活动。共享计数器要使用并发安全的数据结构，不能把普通 map 当成无锁统计容器。

另外，官方文档把当前追踪范围限定为一次请求—响应往返，并没有覆盖一串重定向请求的全链路钩子。如果你要为重定向链路建立统一记录，应在更上层为每次请求分配关联 ID，而不是假设一次 Got1xxResponse 能代表整个链路。

最终的 Response.Body 仍由调用方关闭。Got1xxResponse 只处理信息响应头，不能替代 defer resp.Body.Close()，也不能在回调里提前关闭最终响应体。

常见问题

配置了 Got100Continue 后还会收到 100 的 Got1xxResponse 吗？

会。Go 官方说明中，Got1xxResponse 对 100 Continue 仍然触发，即使同时定义了 Got100Continue。如果两个钩子都做计数，要明确这是两个不同观测入口，避免把一次响应统计成两个业务事件。

Got1xxResponse 能观察服务端处理器发出的所有状态吗？

不能把它当作服务端监控接口。它只在客户端这一次 HTTP 往返中观察收到的 1xx 响应头；最终响应、重定向链路和服务端内部执行过程仍要通过各自的日志、指标或追踪方案记录。