Go http.NewRequest 怎样让请求体支持重定向重放

如果 Go 客户端发出的 POST 请求遇到需要保留原方法和请求体的重定向，关键不是把 req.Body 再读一遍，而是让请求拥有能够返回“全新 body”的 GetBody。使用 http.NewRequest 时，*bytes.Buffer、*bytes.Reader 和 *strings.Reader 会自动获得准确的 ContentLength 与 GetBody；自定义 io.Reader 则需要自己保证可重复生成。

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

排查这类问题时先看三个字段：Body 负责第一次发送，GetBody 负责按需创建下一份 body，ContentLength 表示长度是否明确。只有把“可读取”和“可重新创建”分开，重定向重放才不会因为 body 已经到 EOF 而丢失正文。

• 307/308 需要保留原方法和 body 时，客户端会依赖 GetBody。
• 常见内存型 reader 由 NewRequest 自动补齐长度和重放函数。
• 自定义或一次性流没有天然副本，必须从可重复的数据源重新构造。

先看 Body、GetBody 和 ContentLength 的分工

Body 是当前这一次发送使用的读取器；它被消费后通常不能回到开头。GetBody 是一个可选函数，职责是返回一份新的 io.ReadCloser，用于客户端需要再次读取请求体的场景。它不是“把现有 Body 重置”的方法，也不能只返回同一个已经读过的对象。

ContentLength 只描述长度是否已知，不等于请求体是否可重放。长度是明确的 reader 可能没有 GetBody，而实现了 GetBody 的自定义 reader 也可以把长度设为未知。因此线上排查要把这两个字段分开记录。

为什么 bytes.Reader 能自动支持重放

NewRequest 对 *bytes.Buffer、*bytes.Reader 和 *strings.Reader 有专门处理：它可以取得当前数据长度，并保存构造下一份 reader 所需的信息。这样遇到需要重新发送正文的情况时，新的 body 从相同内容重新开始，而不是复用已经读到一半的旧对象。

package main

import (
    "bytes"
    "fmt"
    "net/http"
)

func main() {
    payload := []byte(`{"event":"sync","count":2}`)

    // bytes.Reader 让 NewRequest 能知道长度，并自动准备 GetBody。
    req, err := http.NewRequest(http.MethodPost, "https://api.example.com/events", bytes.NewReader(payload))
    if err != nil {
        // URL 或方法非法时立即终止，避免把半成品请求交给 Client。
        panic(err)
    }
    req.Header.Set("Content-Type", "application/json")

    fmt.Println("length:", req.ContentLength)
    fmt.Println("replayable:", req.GetBody != nil)
}

这里的判断重点是 req.GetBody != nil，而不是只看 req.Body != nil。如果只把一段已经读过的 io.Reader 交给 NewRequest，首次发送也许正常，但客户端没有办法凭空恢复被消费的内容。

自定义 reader 怎样补上安全的 GetBody

当正文来自压缩流、文件流或业务自定义 reader 时，不要假设它可以重复读取。更稳妥的方式是在请求创建前保留一份可重建的数据，或者把“生成新 reader”的逻辑封装成函数。下面的例子把原始字节作为不可变源，每次调用都返回独立的 reader。

package main

import (
    "bytes"
    "fmt"
    "io"
    "net/http"
)

func newReplayableRequest(payload []byte) (*http.Request, error) {
    // 复制源数据，避免调用方后续修改切片导致重放内容漂移。
    source := bytes.Clone(payload)
    req, err := http.NewRequest(http.MethodPut, "https://api.example.com/items/7", bytes.NewReader(source))
    if err != nil {
        return nil, err
    }

    // 每次都创建新的 reader，不能复用已经读过的 Body。
    req.GetBody = func() (io.ReadCloser, error) {
        return io.NopCloser(bytes.NewReader(source)), nil
    }
    req.ContentLength = int64(len(source))
    req.Header.Set("Content-Type", "application/json")
    return req, nil
}

func main() {
    req, err := newReplayableRequest([]byte(`{"name":"demo"}`))
    if err != nil {
        panic(err)
    }
    copyBody, err := req.GetBody()
    if err != nil {
        panic(err)
    }
    defer copyBody.Close() // 关闭每次新建的副本，保持资源生命周期清晰。

    data, err := io.ReadAll(copyBody)
    if err != nil {
        panic(err)
    }
    fmt.Println(string(data))
}

自定义 GetBody 只解决“能否生成下一份 body”，不会替你修复并发修改、文件位置变化或一次性网络流等问题。若源数据来自文件，函数里应重新打开文件并从固定位置开始，同时把打开失败如实返回。

上线前怎么处理未知长度和不可重读流

如果 body 是 io.PipeReader、网络流或其他一次性输入，通常无法安全地为重放保留完整副本。这时不要为了让字段看起来完整而随意设置 ContentLength：错误的长度会影响请求发送。可以根据业务选择提前落盘、限制大小后缓存在内存、关闭需要保留正文的重定向，或者在重定向前重新构造一份请求。

排查时建议记录以下信号：

• GetBody == nil：当前请求没有自动重放能力，需要补函数或改变数据源。
• ContentLength == -1：长度未知，不能把它当作正文为空。
• GetBody 返回错误：新副本创建失败，应停止重试并保留根因。
• 重放副本为空：检查闭包引用的数据是否被修改，以及每次是否真的新建 reader。

最后把这几个字段纳入客户端日志或调试指标即可，不必打印真实请求正文。这样既能定位 body 已消费的问题，也能避免把敏感数据写入日志。

常见问题

设置了 ContentLength 就一定可以重定向重放吗？

不一定。ContentLength 只说明长度，重放还需要 GetBody 能够返回新的 body。

GetBody 可以返回同一个 Body 吗？

不建议。每次应返回独立的可读对象；复用已经消费过的 reader 会得到空内容或不完整内容。

为什么普通自定义 bytes.Buffer 也可能失去重放能力？

如果传入的是包装后的接口类型或一次性 reader，NewRequest 未必能识别其底层数据。需要在请求创建前保留源数据，或显式设置 GetBody。

重放失败时应该继续重试吗？

先判断新 body 是否能从同一份源数据稳定构造；如果源数据已丢失或不可重复，应停止自动重试，改用可缓存输入或明确的重定向策略。