最可靠方式是实现自定义 roundtripper 接口并委托给 http.defaulttransport，确保复用连接、超时等行为；需用 io.teereader 安全记录 body，避免消耗流；日志应结构化且脱敏，禁用 http.defaultclient。
用 RoundTripper 拦截所有请求最可靠
Go 的 http.Client 默认不提供全局请求日志钩子，RoundTripper 是唯一能稳定捕获每个请求/响应的入口。别试图在 http.HandlerFunc 或中间件里做这事——那是服务端逻辑，对出站请求完全无效。
常见错误是直接包装 http.DefaultTransport 却忘了它本身是 *http.Transport 类型，不能直接赋值给 RoundTripper 字段（类型不匹配）。正确做法是实现自定义 RoundTripper 接口，内部委托给真实 transport。
- 必须保留原始
http.Transport的连接复用、超时、重试等行为，不能自己 new 一个空 struct - 不要在
RoundTrip方法里读取resp.Body后直接返回——这会消耗 body，下游 handler 拿不到数据 - 若需记录响应体，得用
io.TeeReader或复制 body，且注意大文件场景的内存风险
logrus + http.RoundTripper 组合实操
用 logrus 记录结构化日志最实用，但要注意：日志字段必须从 *http.Request 和 *http.Response 中安全提取，比如 req.URL.String() 可能含敏感参数，resp.Status 在 resp 为 nil 时会 panic。
示例关键片段：
type loggingRoundTripper struct {
rt http.RoundTripper
log *logrus.Logger
}
func (l *loggingRoundTripper) RoundTrip(req *http.Request) (*http.Response, error) {
l.log.WithFields(logrus.Fields{
"method": req.Method,
"url": req.URL.String(),
"headers": req.Header,
}).Debug("outgoing request")
resp, err := l.rt.RoundTrip(req)
if err != nil {
l.log.WithError(err).Warn("request failed")
return resp, err
}
l.log.WithFields(logrus.Fields{
"status": resp.Status,
"status_code": resp.StatusCode,
"duration_ms": resp.Header.Get("X-Request-Duration"), // 若服务端写了这个头
}).Info("response received")
return resp, nil
}
- 初始化 client 时必须显式传入该 roundtripper：
&http.Client{Transport: &loggingRoundTripper{rt: http.DefaultTransport, log: log}} - 别用
http.DefaultClient，它用的是默认 transport，你包的 roundtripper 不会被调用 - 如果用了
gorilla/handlers等库的客户端池，确保每个 client 都配置了你的 roundtripper
记录请求/响应体的边界条件
记 body 看似简单，实际容易卡死或丢数据。根本原因是 http.Response.Body 和 http.Request.Body 都是一次性读取流，读完就 EOF。
- 记录请求体前，先用
io.ReadCloser包装原始 body，并用io.TeeReader把内容写进 buffer，再把 buffer 作为新 body 传下去 - 记录响应体时，必须用
io.NopCloser(bytes.NewReader(buf))重建 body，否则下游代码会报body closed - 生产环境慎记完整 body，尤其上传文件或大 JSON；建议只记前 1024 字节，加
truncated标识 - 注意
Content-Encoding: gzip场景——body 是压缩后的，解压需额外处理，否则日志里是乱码
HTTP/2 和连接复用对日志的影响
Go 1.6+ 默认启用 HTTP/2，http.Transport 复用 TCP 连接，但日志中看到的 req.RemoteAddr 是空的，因为底层走的是 h2 stream，不是传统 socket。
- 想区分不同请求的网络路径？别依赖
RemoteAddr，改用req.Context().Value()注入 traceID - 连接复用下，同一 transport 的多个请求共享 TLS 握手和 DNS 缓存，日志里看不到“新建连接”事件，这是正常行为，不是漏日志
- 若需统计连接级指标（如 TLS 版本、证书信息），得在
Transport.DialContext或TLSClientConfig.GetClientCertificate钩子里埋点，不在RoundTrip范围内
真正难的不是写日志，而是让日志既不干扰业务逻辑，又能在故障时快速定位到哪一跳出了问题。body 截断长度、context 透传、错误分类粒度——这些细节没调好，日志反而成噪音源。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
