Go httptrace.Got1xxResponse 怎么记录 103 Early Hints

要记录 Go HTTP 客户端收到的 103 Early Hints，在 httptrace.ClientTrace 中设置 Got1xxResponse，通过 WithClientTrace 把它绑定到实际发出的请求 Context，再在回调中筛选状态码 103。回调只提供中间响应的状态码和头部；Client.Do 返回的 Response 仍用于处理最终响应及其 Body。

官方地址：https://pkg.go.dev/net/http/httptrace

最终状态是 200，为什么日志里找不到 103

假设值班时要确认入口是否把 Early Hints 送到 Go 客户端，而现有日志只记录 resp.StatusCode。我会先分开两个问题：最终请求是否成功，以及客户端是否观察到过 103。前者不回答后者，最终状态正常也不能证明中间提示存在。这是排查场景示例，不是一次实际线上事故记录。

Got1xxResponse 面向最终非 1xx 响应前的信息响应头。103 属于需要在回调中观察的情况；不能期待在最终 resp.Header 里自动保留一份完整的 103 头部。一次请求也可能观察到多个信息响应，记录结构不应只有一个会被反复覆盖的状态码变量。

我倾向先记录“收到多少次 103、其中有多少个 Link 头值”这样的有限信息，再决定是否需要详细采样。这能回答是否到达，又避免一开始把所有响应头塞进日志。Link 头值个数也不是资源个数，一个头值可能包含多个链接，本例不解析链接语法。

先确认观测回调绑定到了真正发送的请求

创建 trace 对象本身不会启用观测，必须用返回的新 Context 构造请求副本，并把副本交给 Client.Do。常见遗漏是调用 WithContext 却没有保存返回的请求，结果发出的仍是原对象。

另一个边界是 Transport：这里针对 net/http 支持 httptrace 的传输实现。自定义 RoundTripper 若完全自行构造响应且不调用这些钩子，仅在 Context 中放入 trace 不会让事件凭空出现。排查时应先确认客户端实际使用哪一层传输封装。

用请求级计数记录 103，同时保留最终响应处理

下面是可放入应用的函数。调用者传入上下文、客户端和目标地址；是否真的收到 103 由服务端与链路决定。示例没有启动服务或伪造回调日志，计数为零也是一种允许的观测结果。

package hints

import (
    "context"
    "fmt"
    "io"
    "log"
    "net/http"
    "net/http/httptrace"
    "net/textproto"
    "sync/atomic"
)

func Fetch(ctx context.Context, client *http.Client, target string) error {
    req, err := http.NewRequestWithContext(ctx, http.MethodGet, target, nil)
    if err != nil {
        return fmt.Errorf("创建请求: %w", err)
    }

    var seen atomic.Int64
    trace := &httptrace.ClientTrace{
        Got1xxResponse: func(code int, header textproto.MIMEHeader) error {
            if code == http.StatusEarlyHints {
                // 请求级原子计数，避免把共享变量当成串行回调使用。
                seen.Add(1)
                // 只记头值数量，不输出可能包含业务信息的完整 Link。
                log.Printf("event=early_hints code=%d link_values=%d",
                    code, len(header.Values("Link")))
            }
            // 这里只观察；返回错误会影响主请求。
            return nil
        },
    }
    req = req.WithContext(httptrace.WithClientTrace(req.Context(), trace))

    resp, err := client.Do(req)
    if err != nil {
        return fmt.Errorf("执行请求: %w", err)
    }
    defer resp.Body.Close()

    // Body 属于最终响应；消费并关闭它，单独处理读取错误。
    _, err = io.Copy(io.Discard, resp.Body)
    if err != nil {
        return fmt.Errorf("读取最终响应: %w", err)
    }
    log.Printf("event=final_response status=%d observed_103=%d",
        resp.StatusCode, seen.Load())
    return nil
}

代码使用 io.Discard 是为了聚焦观测任务，实际业务可以在相同位置解析最终 Body。client 应为非 nil，并配置合适的超时或由传入 Context 设置期限，避免观测示例变成无期限等待。函数没有把最终 4xx、5xx 自动转换成 error；业务若要求成功状态，需要另行判断 StatusCode。

我把事件名刻意拆成 early_hints 和 final_response：这样检索时不容易把 103 计入最终成功或失败统计。示例只表示代码职责，不承诺已测得某个次数或耗时。

回调里的错误、并发和头部保存怎么处理

观测回调应尽快返回。日志写入虽然方便，但具体日志目的地可能阻塞；生产环境可使用已有的受控日志组件或有界事件缓冲，并为丢弃事件设置独立计数。不要为了观测额外发起同步远程请求，再把远程日志服务的延迟叠到业务请求上。

Got1xxResponse 返回非 nil 错误会中止客户端请求。因此，当目的只是记录 103 时，不应把普通日志写入失败直接作为该回调的返回值。观测异常与请求失败应分别记录；如果业务明确需要拒绝某种中间响应，则那是另一项主动控制策略。

ClientTrace 的钩子总体允许来自不同 goroutine 的调用，部分钩子还可能晚于请求完成或失败。代码用原子类型保存计数；若改为向共享切片追加头部，应加锁并复制需要保存的值，避免异步处理继续依赖回调传入的可变映射。不要无锁地把所有请求的头部追加到同一个全局 slice。

需要停用时，回到未附加本次 trace 的请求上下文

回退观测功能时，可以在创建请求时跳过本次 WithClientTrace 和回调构造，让请求继续使用原先的父 Context。不要传 nil trace：WithClientTrace 不接受 nil。也不要以为空 trace 一定清除了已有钩子，它会与父 Context 中已有 trace 组合。

如果应用框架已经注入其他 trace，应由那一层的配置决定是否停用；本例只撤销自己新增的观测。为每个请求新建 trace，也更容易避免把闭包里的计数关联到错误的请求上。

日志怎样判断，复盘记哪些内容

复盘时记录实际 Transport、请求关联标识、观测开关和最终响应状态。出现“没有 103”时，先查绑定和过滤条件，再检查服务端与中间层相关配置；本篇不把缺少事件当作单一故障结论，也不通过改造中间响应来代替排查。

相关问题

Got100Continue 能记录 103 吗？它针对 100 Continue，记录 103 应使用 Got1xxResponse 并筛选状态码。

已经设置 Got100Continue，Got1xxResponse 还会收到 100 吗？官方文档明确会，因此泛 1xx 统计要避免把两个钩子的计数直接相加。

记录 Link 是否会自动预加载资源？本例只记录信息，没有创建资源下载逻辑。

参考：Go ClientTrace 接口文档、Go trace 钩子定义。