Go语言记录HTTP请求日志方法

本文深入讲解了在Go语言中安全、高效地记录HTTP请求日志的最佳实践，直击标准库不支持请求/响应体日志的痛点：强调必须使用`io.TeeReader`/`io.TeeWriter`旁路拷贝body以避免破坏HTTP流，推荐通过自定义`RoundTripper`实现全局、无侵入的日志拦截，并详解如何结构化提取method、URL、状态码、耗时及关键header等安全字段（规避敏感信息泄露与序列化panic），同时明确指出`httputil.DumpRequestOut`仅适用于本地调试、线上禁用的原因——内存失控风险与非结构化输出缺陷；最终点明日志设计的本质不是技术实现，而是围绕业务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 和可观测性需求定，没法套模板。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。