Go Request.GetBody 为 nil 时重试上传失败怎么办

如果 Go 上传请求里的 Request.GetBody 是 nil，先不要把它当成“请求不能发送”。它表示这个请求没有提供一份可重新创建的 Body 工厂：第一次发送可能正常，但重定向重放或自定义重试时，客户端无法自动拿到第二份请求体。修复重点是保存可复用的数据，并让每次尝试都创建新的 http.Request 和 Body。

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

GetBody 是可选的“重新取得请求体”函数，不是通用的 rewind 开关。使用 bytes.Reader、bytes.Buffer 或 strings.Reader 构造请求时，NewRequest 会自动填充它；文件流、管道和自定义 reader 通常需要自己提供工厂，应用层重试则更适合从原始 payload 重新构造 Request。

• 先分清场景：GetBody 主要服务于需要重复读取 Body 的客户端重定向，业务重试仍需自己决定是否重试。
• 先查类型：NewRequest 对三类常见内存 reader 有特殊处理，任意实现 io.Reader 的对象不等于可复制。
• 再改重试：每次尝试都新建 Body，处理完响应后关闭它，并限制次数、退避和可重试状态。

为什么 Request.GetBody 会是 nil

http.Request 同时包含 Body 和可选的 GetBody。前者是本次发送要读取的流，后者返回一份新的 io.ReadCloser，供客户端在需要重复读取请求体时使用。官方文档特别说明，GetBody 仍然需要和 Body 一起设置，服务端收到的 Request 不使用它。

调用 http.NewRequest 或 http.NewRequestWithContext 时，如果传入的是 *bytes.Buffer、*bytes.Reader 或 *strings.Reader，标准库可以知道数据范围，于是自动设置精确的 ContentLength 和 GetBody。换成 io.Reader 包装器、*os.File、io.PipeReader 或自定义 reader 后，标准库无法安全猜测怎样从头复制，GetBody 为 nil 是正常边界。

先判断你需要的是重定向重放还是业务重试

GetBody 的官方语义是“当客户端重定向需要多次读取请求体时，返回一份新的 Body”。例如，使用 307 或 308 重定向时，原请求的方法和请求体可能需要继续带到新地址；这时一个可用的 GetBody 能让客户端重放请求。它并不意味着 Client.Do 会在任意网络错误、超时或 5xx 响应后自动重复上传。

如果问题是业务层的“上传失败后再试一次”，不要只写 req.Clone(ctx)。Clone 对 Body 只是浅复制，原 Body 已经被读取后，克隆对象仍可能面对同一个已消耗的流。先用一个最小检查确认请求体来源，便于快速定位：

package main

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

func main() {
	payload := []byte(`{"name":"demo"}`)
	req, err := http.NewRequest(http.MethodPost, "https://api.example.test/upload", bytes.NewReader(payload))
	if err != nil {
		// 请求构造失败时不要继续读取 GetBody。
		panic(err)
	}

	// bytes.Reader 属于标准库能够自动复制的 reader 类型。
	fmt.Println(req.Body != nil, req.GetBody != nil)
}

上面的 GetBody 非 nil 只说明请求具备重新取得 Body 的能力，并不代表上传已经成功，也不代表所有错误都值得重试。真正的重试还要结合方法是否幂等、服务端是否支持幂等键，以及错误是否发生在服务端已经接收数据之后。

用请求工厂保证每次重试都有新 Body

对 JSON、表单或已经落在内存中的小文件，最直观的办法是把原始字节视为只读输入，封装一个 requestFactory。每轮都从同一份 payload 创建新的 bytes.Reader，再交给 NewRequestWithContext。这样即使上一次 Body 已经读到 EOF，也不会污染下一轮。

package upload

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

func upload(ctx context.Context, client *http.Client, endpoint string, payload []byte) error {
	requestFactory := func() (*http.Request, error) {
		// 每次调用都创建新的 reader，避免复用已经读过的 Body。
		req, err := http.NewRequestWithContext(ctx, http.MethodPost, endpoint, bytes.NewReader(payload))
		if err != nil {
			return nil, err
		}
		req.Header.Set("Content-Type", "application/json")
		return req, nil
	}

	const maxAttempts = 3
	for attempt := 1; attempt = http.StatusInternalServerError && attempt = http.StatusBadRequest {
			return fmt.Errorf("upload failed: %s", resp.Status)
		}
		return nil
	}
	return fmt.Errorf("upload failed after %d attempts", maxAttempts)
}

如果上传内容来自文件，不必一次性把大文件全部读进内存，可以让工厂在每轮重新 os.Open 文件，并把新文件句柄同时作为 Body。关键仍然是“每轮得到独立 reader”，而不是强行给同一个已经读过的流加一个看似可用的 GetBody。

重试上传时最容易忽略的边界

第一，POST 上传即使技术上可以重发，也不一定业务上安全：服务端可能已经写入对象，客户端只是没有及时拿到响应。需要重复提交时，优先使用服务端支持的幂等键，或让服务端按业务 ID 去重。

第二，别把所有 4xx 都重试。参数错误、权限失败和资源不存在通常应该直接返回；网络暂时中断、明确的 5xx 或服务端约定的限流响应，才可能进入有限重试。每次重试都应有上限和退避，避免多个客户端同时放大故障。

第三，Request.GetBody 不是“上传内容已经缓存”的证明。它只描述如何取得新 Body；如果闭包引用了会被修改的缓冲区、已关闭的文件或一次性的管道，重试仍会得到错误数据。保存稳定输入、在工厂内部创建资源，并对每个返回的 Body 负责关闭，边界才是完整的。

Request.GetBody 常见问题 FAQ

为什么 bytes.Reader 有 GetBody，而 io.Reader 没有？

接口只描述“可以读取”，没有描述如何回到起点或复制一份。bytes.Reader 等类型明确保存了可复制的内存范围，NewRequest 才能安全自动填充；普通 io.Reader 不具备这个保证。

手动设置 GetBody 后就能自动重试吗？

不能。手动 GetBody 主要解决客户端需要再次读取 Body 的场景；业务层遇到网络错误或 5xx 时，仍需自己决定重试条件、次数、退避、幂等性和响应体关闭。

因此，遇到 GetBody 为 nil 时，先检查请求体是否来自可复读数据，再区分重定向和业务重试。对需要重复上传的内容，用原始 payload 或可重新打开的文件建立请求工厂，通常比复用 Request 或强行倒回同一个流更可靠。