Go语言日志中间件怎么记录外部API调用耗时-Golang-PHP中文网

必须用http.roundtripper，因它能捕获dns解析、tls握手、连接复用等待、响应体流式读取等全链路耗时；需在roundtrip入口打点、包装resp.body并在close中补全终点时间。

go语言日志中间件怎么记录外部api调用耗时

Go 中记录外部 API 调用耗时必须用 `http.RoundTripper`

标准库里唯一能捕获 DNS 解析、连接建立、TLS 握手、响应体读取等全链路耗时的位置，就是自定义 http.RoundTripper。你在业务层调用 http.Client.Do() 或封装一个 api.Call() 函数打点，漏掉的耗时可能高达几百毫秒——尤其是首次请求、高延迟网络或流式接口（如 SSE）场景。

常见错误包括：

在 Do() 前后调用 time.Now()：只覆盖「发起请求」到「拿到 *http.Response」之间，不包含 resp.Body.Read() 和 Close() 阶段
把计时逻辑塞进中间件（比如 Gin 的 Use()）：那只是服务端内部处理耗时，和外部调用无关
直接改写 http.DefaultTransport 字段：它是全局可变变量，高并发下会引发竞态

怎么包装 `RoundTrip` 并劫持 `resp.Body`

核心是两件事：入口打点 + 出口补点。入口在 RoundTrip 开始时记 start := time.Now()；出口不能靠 RoundTrip 返回就结束，必须包装 resp.Body，在它的 Close() 方法里才算真正完成。

实操要点：

RoundTrip 内部先调 t.base.RoundTrip(req)，拿到 resp 后立刻包装 resp.Body，不要做任何阻塞操作
自定义 timingReadCloser 类型需嵌入原 io.ReadCloser，重写 Close()，并在其中调用 time.Since(start)
别在 Close() 里做日志打印或网络上报——用 channel 异步投递，避免阻塞后续读取
如果请求失败（err != nil），也要在 RoundTrip 内记录耗时，否则错误请求永远不进监控

示例关键片段：

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

type timingReadCloser struct {
    io.ReadCloser
    req   *http.Request
    start time.Time
}
<p>func (t *timingReadCloser) Close() error {
duration := time.Since(t.start).Milliseconds()
// 投递到 statsChan，不阻塞
statsChan </p><h3>为什么必须包装 <code>resp.Body</code> 而不只是看 <code>RoundTrip</code> 返回时间</h3><p>HTTP 响应体是流式读取的。<code>RoundTrip</code> 返回时，TCP 连接可能还在传输数据，<code>resp.Body.Read()</code> 可能阻塞数秒，尤其在大文件下载、JSON 流、SSE 场景下。不包装 <code>Body</code>，你统计的只是「发出去又收到 header」的时间，不是真实端到端耗时。</p><p>容易被忽略的细节：</p>

同一个 resp.Body 可能被多次 Read()，但只有 Close() 是确定的终点
若业务代码忘了调用 resp.Body.Close()，耗时永远不会上报——需配合 context.WithTimeout 或 defer resp.Body.Close() 确保执行
包装后的 timingReadCloser 必须透传所有 Read() 调用，不能拦截或修改内容，否则破坏业务逻辑