Go http.Client 307 重定向为什么没有带上请求体

Go 的 http.Client 遇到 307 或 308 重定向时，并不是简单地把原请求复制一份。规范语义要求它保留原来的请求方法和请求体，但客户端只有在 Request.GetBody 能重新生成一份请求体时，才有条件继续发送。使用 bytes.Reader、strings.Reader 等常见输入通常没有问题；自定义流式 io.Reader 没有重建函数时，就可能看到“第一次请求有 body，重定向后 body 没了”的现象。

本文只讨论 Go 标准库客户端的 307/308 请求体边界。官方文档入口：https://pkg.go.dev/net/http#Client.Do

先分清 301/302 与 307/308

排查前先看响应状态码。301、302、303 在 Go 客户端的重定向处理中可能把后续请求改成 GET；307、308 则要求保留原方法和请求体。也就是说，POST 收到 307 后，客户端要再次发送 POST，并且要拿到一份新的 body。

因此，看到重定向后的服务端没有收到 JSON 时，第一步不是马上关闭自动重定向，而是确认原始请求是否有可用的 GetBody。

为什么 NewRequest 有时能自动重建请求体

http.NewRequest 接收的是 io.Reader，但它会识别几种常见的具体类型，并为请求设置可重复读取的能力。官方文档特别提到，*bytes.Buffer、*bytes.Reader 和 *strings.Reader 这类输入可以自动提供 GetBody，同时设置合适的内容长度。

下面这个例子使用字节切片构造 POST 请求。代码没有发起真实网络调用，只展示请求对象边界：

package main

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

func main() {
    payload := []byte(`{"name":"demo"}`)

    // bytes.Reader 是 NewRequest 能识别的常见 Reader，通常会得到 GetBody。
    req, err := http.NewRequest(http.MethodPost, "https://api.example.test/items", bytes.NewReader(payload))
    if err != nil {
        panic(err)
    }

    // 只检查是否具备重建能力，不把检查结果当成真实网络响应。
    fmt.Println(req.GetBody != nil, req.ContentLength)
}

如果把输入换成一个只能读取一次的自定义流，NewRequest 没有足够信息复制它。此时第一次发送可能正常，重定向后却不能安全地恢复同一份内容。

自定义 Reader 需要自己提供 GetBody

补充 GetBody 的关键是保留一份不会被第一次读取破坏的源数据，每次调用都返回新的 io.ReadCloser。不要把已经读过的原始 Body 直接再次赋给请求。

package main

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

func newPostRequest(payload []byte) (*http.Request, error) {
    // 复制输入，避免调用方后续修改底层数组影响重定向重放。
    stable := append([]byte(nil), payload...)
    req, err := http.NewRequest(http.MethodPost, "https://api.example.test/items", bytes.NewReader(stable))
    if err != nil {
        return nil, err
    }

    // 每次重定向都从稳定副本创建新的读取器，不能复用已到 EOF 的 Body。
    req.GetBody = func() (io.ReadCloser, error) {
        return io.NopCloser(bytes.NewReader(stable)), nil
    }
    req.Header.Set("Content-Type", "application/json")
    return req, nil
}

对于大文件、压缩流或加密流，不要为了跟随 307 而盲目把全部数据读进内存。可以改用可重复打开的文件、临时对象或业务层重试协议，但要明确数据所有权、清理时机和重放成本。

用 CheckRedirect 控制链路长度

请求体能够重建，并不意味着应该无限跟随重定向。可以在 CheckRedirect 中限制跳数；当策略返回 http.ErrUseLastResponse 时，客户端会停止跟随并把原始重定向响应交给调用方，适合记录 Location 或做业务判断。

client := &http.Client{
    CheckRedirect: func(next *http.Request, via []*http.Request) error {
        // via 是已经走过的请求链；这里最多允许 3 次跳转。
        if len(via) >= 3 {
            // 保留当前 3xx 响应，方便调用方读取 Location，而不是继续发送。
            return http.ErrUseLastResponse
        }
        return nil
    },
}

如果 CheckRedirect 返回普通错误，Client.Do 会返回一个 *url.Error；这与服务端返回 4xx/5xx 不是一回事。排查时要同时记录错误类型、响应是否存在以及最终 URL。

几个容易误判的现象

发布前的最小速查

1. 确认服务端返回的是 307/308，而不是 301/302/303。
2. 在构造请求后记录 GetBody != nil，不要把已读完的 Body 当作可重放源。
3. 对自定义 Reader 保存稳定数据源，并让每次 GetBody 返回新的读取器。
4. 给 CheckRedirect 设置合理上限；不跟随时选择明确的错误或 ErrUseLastResponse。
5. 独立处理网络错误、重定向策略错误和非 2xx 响应。

相关问题

307 和 308 在请求体处理上有什么差别？

两者都要求保留请求方法和请求体，主要差别在重定向的永久性语义。对客户端实现来说，二者都需要可重建的 body。

为什么设置了 Content-Length 仍然没有 body？

Content-Length 只描述长度，不会把已经消费的 Reader 变回可读数据。重定向重放依赖 GetBody 或其他可重复读取来源。

能否直接把 Body 重新指向同一个 bytes.Buffer？

不建议。第一次读取可能已经改变 buffer 的读取位置；应保留稳定副本，并为每次重放创建新的 Reader。