HTTP client请求日志应使用io.TeeReader/io.TeeWriter旁路拷贝body，避免破坏流；全局日志用自定义RoundTripper，安全提取method、url、status_code、duration_ms等字段，禁用httputil.DumpRequestOut。
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、耗时、状态码等关键信息。
立即学习“go语言免费学习笔记（深入）”；
- 必须复制
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 和可观测性需求定，没法套模板。
