必须用自定义ResponseWriter包装器捕获响应体，通过重写Write方法将字节同步写入bytes.Buffer或io.MultiWriter；httptest.NewRecorder仅适用于测试且不支持流式响应，生产环境需限制采样、截断长度并脱敏敏感字段。

日志中间件怎么拿到响应体内容

原生 http.ResponseWriter 不暴露响应体字节，直接读不到。必须用包装器捕获 Write 和 WriteHeader 调用，否则日志里只有状态码和耗时，没有实际响应数据。

• 用 httptest.NewRecorder() 最简单，但它不支持流式响应（比如大文件下载、SSE），且会把全部响应体缓存在内存中
• 更通用的做法是实现自定义 ResponseWriter，重写 Write 方法，把写入内容同时拷贝到 bytes.Buffer 或 io.MultiWriter
• 别试图在 next.ServeHTTP() 之后再去读 w —— 此时响应已 flush，Write 可能已返回错误或被忽略
• 如果下游 handler 写了多次 Write（比如分块渲染），你的包装器要能累积拼接，不能只取最后一次

为什么 statusRecorder 不能代替响应体捕获

statusRecorder 是常见误区：它只记录状态码、header 和响应大小，不保存响应体字节。它的作用是防止日志误记 200（比如 handler panic 后 net/http 默认写 500，但没被中间件捕获）。

• statusRecorder 的典型用法是包装 ResponseWriter，覆盖 WriteHeader 和 Write，仅缓存状态与长度
• 想记响应体，你得额外加一层 io.TeeWriter 或手动 io.Copy 到 buffer
• 二者可共存：用 statusRecorder 保状态码 + 自定义 writer 保 body，但要注意写顺序和并发安全

响应体太大时怎么安全采样

全量记录响应体会导致 OOM 或磁盘打爆，尤其遇到文件下载、导出 CSV、大 JSON 返回等场景。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

• 限制最大捕获长度，比如只取前 10240 字节（10KB），超出部分用 "[truncated]..." 标记
• 按 Content-Type 过滤：只记录 application/json、text/plain 等可读类型，跳过 image/*、application/octet-stream
• 加采样开关：比如每 100 个请求记 1 个，或只记录非 2xx 响应，避免日志噪音
• 生产环境禁用全量 body 日志，调试阶段再开；上线前务必压测内存占用

中间件里怎么把响应体塞进日志结构体

拿到响应体字节后，不能直接塞进结构体字段打日志——要先做安全处理，否则可能引入敏感信息泄露或格式破坏。

立即学习“go语言免费学习笔记（深入）”；

• 响应体是 []byte，转 string 前检查是否为 UTF-8（用 utf8.Valid()），否则用 fmt.Sprintf("%x", body) 十六进制输出
• 敏感字段如 "password"、"token" 需正则脱敏，不要依赖前端传来的字段名，要扫描 JSON 键路径
• 日志结构体字段建议命名为 resp_body_snippet 而非 response_body，明确表示非全量
• 如果用了 zap，用 zap.Binary("resp_body", body) 比 zap.String 更稳妥，避免编码问题

真正难的不是“怎么拿到”，而是“什么时候该不拿”——响应体日志是双刃剑，开得随意，排查问题时帮倒忙，关得太死，关键链路又缺上下文。留心 Content-Length 头、判断流式场景、设置硬性截断阈值，比写对那几行 io.Copy 更重要。