Go httputil.DumpResponse 记录响应后怎么保留 Body 给业务读取

在 Go HTTP 客户端里，响应体是一个流。调试日志如果先把 resp.Body 读完，后面的 JSON 解码就只能得到空内容。这个场景可以直接交给 httputil.DumpResponse(resp, true)：它会读取响应体用于生成 dump，并把同一批字节重新放回 resp.Body，业务代码随后仍可继续读取。

官方文档：https://pkg.go.dev/net/http/httputil#DumpResponse

一、先分清 DumpResponse 的 body 参数

DumpResponse(resp, false) 适合只记录状态行和响应头，不主动读取响应体；后续业务可以按原来的方式消费 Body。需要同时观察响应内容时才传 true。这个参数不是“是否打印一行日志”，而是“是否把 Body 纳入转储并重新准备给调用方”。

二、记录响应后继续读取业务 Body

下面的示例先记录完整响应，再读取恢复后的 Body。注意关闭动作放在 dump 成功之后，确保关闭的是当前的 resp.Body；如果 dump 失败，则在错误分支直接关闭当前响应。

func readWithResponseLog(client *http.Client, req *http.Request) ([]byte, error) {
	// 发起请求后，resp.Body 仍是一次性读取流。
	resp, err := client.Do(req)
	if err != nil {
		return nil, err // 请求未得到响应，不进入 Body 处理。
	}

	dump, err := httputil.DumpResponse(resp, true)
	if err != nil {
		_ = resp.Body.Close() // dump 失败时不再使用响应，立即释放资源。
		return nil, err
	}
	log.Printf("response dump:\n%s", dump) // 这里只示范记录，生产环境应控制内容范围。

	defer resp.Body.Close() // DumpResponse 已替换 Body，关闭当前可读副本。
	body, err := io.ReadAll(resp.Body)
	if err != nil {
		return nil, err // 业务读取仍可能遇到底层 I/O 错误。
	}
	return body, nil
}

这个顺序解决的是“日志读取和业务读取争抢同一条流”的问题：DumpResponse 先拿到字节，之后把它包装成新的 io.ReadCloser。因此后续 io.ReadAll 读到的不是空流，而是原响应内容。

三、错误、关闭与大响应体的边界

DumpResponse 返回错误时，响应对象的状态不应再被当作可靠输入，调用方要直接走释放和返回错误路径。成功后也不要忘记关闭新的 Body。若把 defer resp.Body.Close() 写在调用 dump 之前，接收者可能已经指向旧的 Body，代码阅读和资源管理都更容易出错。

另一个边界是响应体大小。true 会为了生成完整转储而把 Body 读入内存，文件下载、长列表和大 JSON 不应无条件开启。只看状态与头部时使用 false；需要诊断内容时，可以在业务层设置响应大小上限后再记录，或只记录摘要。本文只讨论读取恢复，不把敏感字段脱敏规则混入这个机制。

四、发布前的四项检查清单

• 日志需要响应体时，是否明确传入 true，而不是依赖默认行为？
• 是否在 dump 成功后再读取 resp.Body，并在所有路径关闭它？
• 大响应体是否有大小、采样或摘要策略，避免调试代码放大内存占用？
• 日志内容是否遵循业务的敏感信息处理规则？这属于应用层策略，不由 DumpResponse 自动完成。

相关问题

DumpResponse(resp, false) 会不会让 Body 变空？

不会主动读取响应体；它适合只记录状态和响应头，后续代码可以继续消费原来的 Body。

为什么 DumpResponse 之后还要重新 Close Body？

成功调用后，响应的 Body 可能已被替换为新的可读副本。业务读取完成后仍需关闭当前字段，才能完成资源生命周期管理。

能不能用 DumpResponse 记录超大下载响应？

不建议无条件这样做。完整 dump 需要收集响应内容，下载和大 JSON 更适合只记录头部、长度和受控摘要。