应通过自定义 RoundTripper 包装 http.DefaultTransport，在 RoundTrip 中安全读取并复用 req.Body 和 resp.Body，记录关键字段（如 Method、URL、Header 中的 User-Agent/X-Request-ID、耗时、StatusCode），敏感信息需过滤，日志逻辑须并发安全。
如何用 RoundTripper 拦截并记录 HTTP 请求详情
Go 的 http.Client 默认不提供请求/响应日志，但你可以通过自定义 RoundTripper 实现完整拦截。这不是加个中间件的事，而是要替换掉底层的传输逻辑——关键在于别破坏原有行为，尤其别漏掉 Close()、别丢掉 body 流。
- 必须包装原
http.DefaultTransport（或你自己的 transport），而不是从头实现RoundTrip - 请求体（
req.Body）是io.ReadCloser，读完后需重置或重建，否则下游服务收不到数据 - 响应体（
resp.Body）同理，想读内容就得用io.TeeReader或先io.ReadAll再塞回io.NopCloser - 别在日志里直接打印
req.Header全量 map——某些 header（如Authorization）敏感，得过滤
怎么安全地读取并复用 req.Body 和 resp.Body
Body 是单次读取流，直接 io.ReadAll(req.Body) 后，原请求就空了。常见错误是忘记重建 body，导致后端 400 或超时。
- 对
req.Body：用bytes.NewReader(b)+io.NopCloser包一层，赋给req.Body - 对
resp.Body：建议用io.TeeReader(resp.Body, writer)边转发边记录，避免内存暴涨（尤其大文件响应） - 如果必须全量读取（比如要打结构化日志），限制最大读取长度（如 1MB），超出则截断并标记
"body_truncated" - 注意
req.Body == nil场景（GET 请求无 body），别盲目调ReadAll
RoundTripper 日志该记哪些字段才真正有用
只记 URL 和状态码意义不大；线上排障需要能还原链路的关键上下文。
Alibabacloud Sdk Client Initialization For Golang
下载
初始化并管理阿里云SDK Go 客户端，涵盖 sync.Once 单例、goroutine 安全、endpoint 与 region 配置、VPC 端点及调试。
- 必记：
req.Method、req.URL.String()、req.Header.Get("User-Agent")、req.Header.Get("X-Request-ID") - 建议记：
time.Since(start)（耗时）、resp.StatusCode、resp.Header.Get("Content-Length") - 谨慎记：
req.Body和resp.Body—— 开关控制，默认关闭，仅 debug 环境开启 - 别记：
req.RemoteAddr（客户端地址在服务端不可信）、resp.Header全量（体积大且含敏感信息如Set-Cookie）
为什么不用 httptrace 或 middleware 方案
httptrace 只能监听连接建立、DNS、TLS 等底层事件，拿不到完整请求头和 body；而所谓 “middleware”（如封装 http.Handler）只适用于服务端，对发起的 outbound 请求无效。
立即学习“go语言免费学习笔记（深入）”；
-
RoundTripper是唯一能统一拦截所有 outbound HTTP 请求的扩展点 - 第三方库如
go-httptracing或roundtripper包只是帮你封装了 body 复用逻辑，核心仍是替换Transport - 如果你用
resty或gqlgen等客户端，它们内部也基于http.Client，所以同样适用自定义RoundTripper - 注意：
http.Transport是并发安全的，你的日志逻辑也必须是——别用全局变量存 request ID，用context.WithValue透传
最易被忽略的是 body 生命周期管理：一次 ReadAll 调用就可能让整个请求静默失败，而错误还不报在你写的代码里，它藏在下游服务的日志中。
