Go语言请求日志记录技巧

本文深入探讨了Go语言中HTTP客户端请求日志记录的正确实践，强调避免使用破坏流的直接读取方式或高风险的`httputil.DumpRequestOut`，转而采用`io.TeeReader`/`io.TeeWriter`实现安全、无侵入的请求/响应体旁路拷贝，并通过自定义`RoundTripper`统一拦截全局请求，在保障性能与稳定性的前提下精准提取method、URL、status_code、耗时及关键headers等结构化字段；同时提醒开发者警惕敏感信息泄露、内存溢出风险与序列化panic陷阱，指出日志设计的本质不是技术实现，而是围绕业务SLA和可观测性需求做出审慎取舍——真正考验功力的，永远是“打什么”和“怎么打”，而非“能不能打”。

HTTP client 请求日志怎么打（不改第三方库）

Go 标准库 http.Client 本身不提供请求/响应体日志，直接打印 req.Body 或 resp.Body 会破坏流——因为 Read 只能读一次，后续 handler 或 json.Unmarshal 就收不到数据了。

正确做法是用 io.TeeReader / io.TeeWriter + bytes.Buffer 做“旁路拷贝”：

• 对请求体：在调用 http.NewRequest 后，把原始 body 包一层 io.TeeReader(body, &buf)，再赋给 req.Body
• 对响应体：在 client.Do(req) 后，用 io.TeeReader(resp.Body, &buf) 包装，再塞进新 http.Response
• 注意：必须在 req.Body.Close() 前完成读取，否则 buf 可能为空

用 http.RoundTripper 实现全局请求日志

如果要统一拦截所有请求（比如调试微服务调用链），别动每个 http.NewRequest，改用自定义 http.RoundTripper。它在请求发出前、响应返回后都有钩子，且不影响业务代码。

常见错误是直接在 RoundTrip 里打印 req.URL.String() 就完事——这漏掉了 header、body、耗时、状态码等关键信息。

• 必须复制 req.Header（避免并发修改）
• 读 body 前先用 req.GetBody()（如果设置了该函数），否则可能 panic
• 记录耗时要用 time.Now() 包裹 rt.RoundTrip() 调用，不是用 resp.Header.Get("Date")
• 生产环境慎用：日志体过大（如文件上传）会吃内存，建议加长度限制（io.LimitReader）

logrus/zap 里怎么结构化打 HTTP 日志

用 logrus.WithFields 或 zap.Object 打日志时，别把整个 http.Request 当字段传——它含未导出字段、闭包、指针，序列化会 panic 或泄露敏感信息（如 req.Header["Authorization"]）。

只提取安全、稳定、有业务意义的字段：

• method: req.Method
• url: req.URL.String()（注意 query 参数是否需脱敏）
• status_code: resp.StatusCode（注意 resp 可能为 nil）
• duration_ms: int64(time.Since(start).Milliseconds())
• header 子集：只取 X-Request-ID、User-Agent 等明确需要的 key，别遍历全部

为什么 httputil.DumpRequestOut 不适合线上日志

httputil.DumpRequestOut 看起来省事，但它会强制读取并缓冲整个 req.Body 到内存，且无法控制大小。线上遇到大文件上传或长流式请求，容易 OOM。

更糟的是：它输出的是原始 HTTP 报文格式（含 CRLF、冒号空格等），不适合结构化解析，也难和 traceID 对齐。

• 仅限本地调试，加 defer + recover 防崩溃
• 永远不要在 RoundTripper 中无条件调用它
• 替代方案：用 golang.org/x/net/http/httpguts 提取 header 字段，手动拼接精简版 log line

真正难的不是打日志，是决定哪些字段该打、打多细、什么时候截断——这些得贴着业务 SLA 和可观测性需求定，没法套模板。

到这里，我们也就讲完了《Go语言请求日志记录技巧》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！