Go HTTP 重定向后为什么请求体无法重放

Go HTTP 客户端在 307 或 308 重定向后无法重放请求体，通常是因为原始 Request.GetBody 为 nil。Body 是已经开始消费的一次性数据流，客户端需要 GetBody 创建一份新的流；当请求体非空却没有这个函数时，net/http 会把 307/308 响应直接返回，而不是继续跟随重定向。

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

先区分哪种重定向需要请求体

一次 POST 得到 3xx 并不代表 Go 都会用同一种方式处理。301、302、303 会让后续请求使用 GET（原请求是 HEAD 时仍为 HEAD），因此不重放 Body；307、308 则保留原方法和 Body，问题才会落到“能不能重新读取”。

如果业务要求 POST 语义和 JSON、表单或文件内容都保持不变，服务端应返回 307 或 308；客户端则必须保证请求体可以重放。不要为了绕过 GetBody，把本应保留 POST 的接口改成会丢弃 Body 的 302。

根因不在重定向，而在 GetBody 为空

Request.Body 的类型是 io.ReadCloser。第一次请求发送时，Transport 会读取并关闭它。307/308 需要构造下一次请求时，客户端不能假定这个流能回到开头，只能调用可选的 Request.GetBody 获得新副本。

下面这种写法看似只是给字符串外面套了一层缓冲，实际上改变了传给 NewRequest 的具体类型，标准库不会自动生成 GetBody：

payload := `{"task":"sync"}`

// bufio.Reader 不在 NewRequest 自动识别的可重放类型列表中
body := bufio.NewReader(strings.NewReader(payload))
req, err := http.NewRequest(http.MethodPost, startURL, body)
if err != nil {
    return err
}

// 这里为 true 时，非空 Body 无法在 307/308 后重新创建
log.Printf("getBodyMissing=%t", req.GetBody == nil)

这类请求不一定返回 Go 错误。对于带非空 Body 且 GetBody 为空的 307/308，客户端会停止自动重定向并把该响应交给调用方。因此最容易误判的现象是：client.Do 没有报错，但最终 resp.StatusCode 仍是 307 或 308。

小请求体直接使用标准库可识别的 Reader

JSON、短表单等可以先保存在不可变字节切片中，再把 *bytes.Reader 传给 http.NewRequest。标准库会设置准确的 ContentLength，并自动填充 GetBody。

payload, err := json.Marshal(input)
if err != nil {
    return fmt.Errorf("编码请求体: %w", err)
}

// bytes.NewReader 会让 NewRequest 自动生成 GetBody
req, err := http.NewRequestWithContext(
    ctx,
    http.MethodPost,
    startURL,
    bytes.NewReader(payload),
)
if err != nil {
    return fmt.Errorf("创建请求: %w", err)
}
req.Header.Set("Content-Type", "application/json")

// 调用前确认请求体确实具备重放能力
if req.GetBody == nil {
    return errors.New("请求体不可重放")
}

resp, err := client.Do(req)
if err != nil {
    return fmt.Errorf("发送请求: %w", err)
}
defer resp.Body.Close() // 及时关闭响应体，便于连接复用

strings.NewReader、bytes.NewReader 和 bytes.NewBuffer 都属于标准库能识别的类型。不要在外面再包一层自定义 Reader 后期待自动推断；一旦具体类型变了，应自己设置 GetBody。

文件请求体要用 GetBody 重新打开

大文件不适合为了重定向全部读进内存。更稳妥的方式是把“重新打开同一个只读文件”封装成 GetBody，并固定 ContentLength。发送期间还要确保文件不会被替换或修改。

info, err := os.Stat(path)
if err != nil {
    return fmt.Errorf("读取文件信息: %w", err)
}

// 每次调用都返回一个独立文件句柄，供初始请求或重定向请求读取
openBody := func() (io.ReadCloser, error) {
    f, err := os.Open(path)
    if err != nil {
        return nil, fmt.Errorf("打开上传文件: %w", err)
    }
    return f, nil
}

firstBody, err := openBody()
if err != nil {
    return err
}

req, err := http.NewRequestWithContext(ctx, http.MethodPut, startURL, firstBody)
if err != nil {
    firstBody.Close() // 请求创建失败时由调用方关闭已打开的文件
    return fmt.Errorf("创建上传请求: %w", err)
}
req.GetBody = openBody
req.ContentLength = info.Size()
req.Header.Set("Content-Type", "application/octet-stream")

如果 Body 来自 io.Pipe、实时压缩、摄像头或持续生成的数据，它本质上没有第二份完全相同的内容。此时不要伪造 GetBody；应通过 CheckRedirect 禁止自动跳转，先解析最终地址后再建立新流，或者让服务端在读取请求体之前完成路由。

能重放以后，还要限制重定向边界

请求体可能包含业务数据，307/308 又会保留方法和内容，因此“可以重放”不是“可以重放到任意地址”。Go 会在重定向到不受信任目标时限制 Authorization、Cookie 等敏感头的转发，但业务仍应显式限制 scheme、主机和最大跳转次数。

client := &http.Client{
    CheckRedirect: func(req *http.Request, via []*http.Request) error {
        // 限制跳转次数，避免重定向环路消耗资源
        if len(via) >= 5 {
            return errors.New("重定向次数过多")
        }

        // 只允许 HTTPS 且目标仍在业务允许的主机列表中
        if req.URL.Scheme != "https" || !allowedHost(req.URL.Hostname()) {
            return fmt.Errorf("拒绝重定向目标: %s", req.URL.Hostname())
        }
        return nil
    },
}

POST、PATCH 等非幂等操作还应带业务幂等键，并让服务端把相同键识别为同一次操作。原因是请求体是否能重放只解决“字节能否再次发送”，并不保证第一次目标完全没有处理副作用。

日志里至少记录这几个判断

• 初始方法、脱敏后的目标主机和最终状态码。
• 发送前 req.GetBody != nil，以及已知的 ContentLength。
• 重定向次数、每次状态码和目标主机，不记录请求体明文与 Authorization。
• CheckRedirect 是允许、拒绝还是命中次数上限。
• 业务幂等键的摘要或内部追踪 ID，避免把隐私数据写进日志。

如果最终响应仍是 307/308，先看 GetBody 和 ContentLength；如果 client.Do 返回 *url.Error，再检查 CheckRedirect 是否主动拒绝。两类现象的处理方向不同。

验证清单

• 服务端要保留方法和 Body 时使用 307/308，而不是依赖 302 的兼容行为。
• 小请求体传入 bytes.Reader、bytes.Buffer 或 strings.Reader。
• 文件通过 GetBody 每次重新打开，并保证发送期间内容稳定。
• 真正的流式 Body 禁止自动重放，不伪造可重复读取能力。
• CheckRedirect 限制 HTTPS、允许主机和最大跳转次数。
• 非幂等请求设置业务幂等键，日志不记录敏感 Body。

常见问题

为什么没有报错，却拿到了 307 响应？

非空 Body 的 GetBody 为空时，Go 会停止跟随 307/308 并返回该响应，而不是把它视为协议错误。

给 Body 调用 Seek(0, 0) 可以替代 GetBody 吗？

不能依赖这个做自动重定向。net/http 判断和创建新 Body 使用的是 GetBody；即使底层对象可 Seek，也应提供明确的新副本函数。

用 http.Post 会自动重放 JSON 吗？

是否可重放取决于最终构造出的 Request.GetBody。需要可靠控制时，使用 NewRequestWithContext、可识别的 Reader，并在发送前检查 GetBody。

301、302 后 Body 不见了也是 GetBody 的问题吗？

通常不是。Go 对 301、302、303 的兼容策略本来就会把非 GET/HEAD 方法改为 GET，并且不携带原 Body。