Golang微服务中如何记录请求响应耗时？-Golang-PHP中文网

必须包装responsewriter才能获取真实状态码，否则日志全为200；需实现writeheader和write方法捕获状态码与响应体，同时兼顾hijack、flush等接口以避免panic。

golang微服务中如何记录请求响应耗时？

HTTP服务端耗时记录必须包装 ResponseWriter

不包装 ResponseWriter，就拿不到真实状态码，日志里全是 200 —— 即使接口返回了 404 或 500。因为 Go 标准库默认状态码是 200，只有显式调用 WriteHeader 才会改，而很多错误路径（比如 JSON 序列化失败、panic 后 recovery 中间件）根本没走这一步。

正确做法是定义一个结构体实现 http.ResponseWriter 接口，重写 WriteHeader 和 Write：

type timingResponseWriter struct {
    http.ResponseWriter
    statusCode int
}

func (w *timingResponseWriter) WriteHeader(code int) {
    w.statusCode = code
    w.ResponseWriter.WriteHeader(code)
}

func (w *timingResponseWriter) Write(b []byte) (int, error) {
    if w.statusCode == 0 {
        w.statusCode = http.StatusOK
    }
    return w.ResponseWriter.Write(b)
}

WriteHeader 是唯一可靠捕获状态码的位置，必须在这里赋值
Write 里补默认 200，覆盖隐式写入导致的状态码丢失
别漏掉 Hijack、Flush 等方法——否则 gzip、streaming 场景会 panic
状态码字段必须是 int 类型，不是指针；避免并发写冲突

客户端请求耗时必须自定义 RoundTripper

只在业务层用 time.Now() + Do() 包裹，漏掉 DNS、连接池等待、TLS 握手、响应体读取 —— 这些阶段加起来可能占总耗时 70% 以上，尤其在跨区域调用或高延迟网络下。

唯一能拿到全链路时间点的位置是 http.RoundTripper.RoundTrip 方法：

Golang Uber Dig

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

下载

type TimingRoundTripper struct {
    base http.RoundTripper
}

func (t *TimingRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
    start := time.Now()
    resp, err := t.base.RoundTrip(req)
    if err != nil {
        recordError(req.URL.Host, time.Since(start).Milliseconds())
        return resp, err
    }
    resp.Body = &timingReadCloser{
        ReadCloser: resp.Body,
        req:        req,
        start:      start,
    }
    return resp, nil
}

base 必须是线程安全的 transport（如 http.DefaultTransport），不能 new 出临时实例
错误路径也要记录耗时，否则超时、拒绝连接等场景完全无数据
必须包装 resp.Body 实现 io.ReadCloser，否则大响应体或 SSE 流式接口的读取耗时无法捕获
别直接改 http.DefaultTransport 字段——它是全局可变结构体，高并发下不安全

中间件里 time.Since() 必须传参进 defer，不能闭包引用变量

写成 defer fmt.Printf("cost: %v", time.Since(start)) 看似简洁，但在 panic、context 超时、提前 http.Error 时，defer 根本不会执行，耗时就丢了。

更隐蔽的问题是：Go 1.22 之前，闭包捕获的是变量地址，不是值，多个 goroutine 并发时 start 可能被覆盖。

正确写法：defer func(s time.Time) { logCost(s) }(start)
起始时间必须在 c.Next()（Gin）或 next.ServeHTTP()（标准库）前获取
结束时间必须在 c.Next() 返回后立刻获取，不能等 defer 触发
单位统一转 Milliseconds() 后四舍五入，避免 12.000000ms 这类干扰项

trace_id 透传和日志字段必须对齐，否则查不到完整链路

没有 trace_id 的耗时日志等于废日志 —— 你没法把一次 API 请求的入口耗时、下游 HTTP 调用耗时、DB 查询耗时串在一起。但很多人把 trace_id 存进 context 后，日志里却没打出来，或者字段名不一致（trace_id vs traceId vs tid），导致 Loki 或 ELK 聚合失败。