Go httputil.DumpRequestOut 读取请求体后为什么还要恢复 Body

调用 httputil.DumpRequestOut(req, true) 时，Go 会把请求体读出来，才能把正文放进调试表示；但这次读取不能让真正要发送的请求体永久变空，所以函数结束前还要把 req.Body 换回可继续读取的副本。简单说：dump 需要消费 Body，后续发送又需要 Body，恢复动作就是把这两个用途隔开。

官方地址：https://pkg.go.dev/net/http/httputil#DumpRequestOut

body=false 时优先只观察请求行和请求头；body=true 时会读取请求体并在正常路径上恢复 req.Body。恢复的是同样的字节内容，不是把原来的读取游标倒回去。

先确认它调试的是客户端发出的请求

DumpRequestOut 面向 outgoing client request，和服务端侧的 DumpRequest 用途不同。它会借助标准 http.Transport 的写出逻辑生成接近线路格式的文本，因此可能包含 Transport 为请求补充的 User-Agent 等字段。

第二个参数是 body bool。传入 false 时，函数不需要把真实正文读进 dump；传入 true 时，调试输出要包含正文，函数就必须先处理 req.Body。这也是很多“打印完请求后，后续发送读不到正文”问题的起点。

body=true 为什么会先把请求体读完

Request.Body 的类型是 io.ReadCloser，它通常表现为一次性的顺序读取器。函数不能在不读取它的情况下知道正文内容，所以源码会先保存原读取器，再把正文读入内存缓冲区，然后得到两份能产生相同字节的读取器：

func dumpWithBody(req *http.Request) ([]byte, error) {
    // true 表示调试表示中需要包含请求正文。
    dump, err := httputil.DumpRequestOut(req, true)
    if err != nil {
        // 读取或关闭请求体失败时，不把不完整的 dump 当成完整请求。
        return nil, fmt.Errorf("dump outgoing request: %w", err)
    }
    return dump, nil
}

这段调用看起来没有手动读取 req.Body，但读取动作已经发生在库内部。库需要一份字节流供“生成 dump”的内部写出路径使用，另一份则留给调用方后续发送。它不是复制一个可以任意回退的文件指针，而是把正文暂存后重新包装成两个独立的 io.ReadCloser。

为什么 dump 完成后还要恢复 req.Body

如果只做“读完并生成文本”，req.Body 的当前位置就已经到达末尾，后续 http.Client.Do(req) 可能发送空正文，或者只能得到残缺内容。对请求调试来说，这会让日志动作改变被调试请求本身，排查结果就失去了意义。

因此源码在生成线路表示后执行恢复：把先前保存的读取器重新放回 req.Body。在正常成功路径上，之后的 Transport 仍能从开头读取原来的字节；恢复的目的不是保留之前的读取位置，而是让后续消费者拿到一份尚未被消费的等价读取器。

func sendAfterDump(client *http.Client, req *http.Request) (*http.Response, error) {
    // 先生成包含正文的调试表示；库会在成功路径恢复 req.Body。
    raw, err := httputil.DumpRequestOut(req, true)
    if err != nil {
        return nil, fmt.Errorf("prepare request dump: %w", err)
    }

    // 仅示例化日志动作；生产环境应先脱敏再记录 raw。
    log.Printf("outgoing request:\n%s", raw)

    // 这里仍然使用同一个 req，正文应从恢复后的 Body 开始读取。
    resp, err := client.Do(req)
    if err != nil {
        return nil, fmt.Errorf("send request: %w", err)
    }
    return resp, nil
}

需要留意的是，恢复机制不代表可以无限次读取正文。每一次新的发送或读取仍然会消费当前的 Body；如果请求要重试、签名或多次发送，应该由调用方明确保存字节并重新构造读取器，而不是把本次 dump 的恢复当成通用重试方案。

body=false 和 body=true 应该怎么选

排障时先问自己是否真的需要正文。只检查方法、URL、请求头或 Transport 添加的字段时，使用 false 能避免读取正文、占用内存，也不会把业务数据写入日志。只有需要确认编码、序列化结果或正文边界时，才在受控环境使用 true。

请求体可能包含密码、令牌、个人信息或大文件。即使 DumpRequestOut 会恢复 req.Body，也不意味着把 raw 原样写进生产日志是安全的。需要正文时，应先限制适用场景、控制体积，并对日志副本做脱敏。

遇到异常时要看哪些证据

如果返回错误，先把错误当作“dump 没有得到完整表示”，不要继续发送一个你无法确认状态的请求。请求体的读取错误、关闭错误、Transport 写出错误都可能让 dump 失败；调用方至少应保留错误上下文，并避免把原始正文附加到错误日志中。

还要区分“dump 结果是近似线路表示”和“网络层实际抓包”。文档说明它用于调试客户端请求，并不是 HTTP/2 原始二进制抓包。要确认实际网络行为，应使用单独的受控观测手段，不要把 dump 文本当成完整的线上证据。

常见问题

DumpRequestOut 会不会永久消耗 req.Body？正常成功路径不会；为了生成正文 dump，它会临时读取并在结束时放回一份能产生相同字节的读取器。

恢复 Body 是不是把原来的读取游标倒回去了？不是。通常是把内存中的正文重新包装成新的读取器，后续消费者从这份等价副本的开头读取。

只看请求头也要传 true 吗？不需要。只看请求头时传 false，可以避免读取和记录正文。

body=true 能不能解决 HTTP 重试？不能。它只保证这次 dump 的请求体处理不破坏正常发送路径；多次发送应由调用方保存正文并按每次请求重新构造 Body。

记住这条判断即可：body=true 是为了让 dump 看见正文，恢复 req.Body 是为了让后续发送仍看见正文；不需要正文时优先使用 body=false，需要正文时则把内存、敏感数据和错误处理一起纳入排障边界。