Go http.Request.Clone 复制请求体时为什么不能重复读取

用 req.Clone(ctx) 复制 Go 的 HTTP 请求时，Header、URL、表单等结构字段会被复制，但 Body 只做浅复制。它仍然指向同一个可读流，所以原请求先执行 io.ReadAll 后，克隆请求再读到的通常就是 EOF。这个结果不是 Clone 失效，而是流只能按游标消费一次。

需要让多个请求读取同一份内容时，先把 Body 读成受限的 []byte，再为每个请求分别创建新的 bytes.Reader；不要把 Clone 当成请求体复制器。

先确认 Clone 复制了什么

官方文档明确写着：Clone 返回带新 context 的深复制，但 Body 字段例外，只做浅复制。源码里的复制顺序也很直白：先整体复制 Request，再单独复制 URL、Header、Trailer、表单和传输编码；没有为 Body 创建新的读取器。

因此，下面的两个请求虽然是不同的 *http.Request，却共享一个 Body 流。读取器内部只有一个当前位置，谁先读，谁就推进它。

用缓存字节重建两个独立 Body

入站请求通常没有可重复生成 Body 的工厂函数，最稳妥的方式是读取一次、关闭原流，再用同一份字节创建两个独立读取器。示例用 io.LimitReader 限制缓存上限，避免把不受控的请求体一次性放进内存：

func cloneBodyForRead(r *http.Request, limit int64) ([]byte, *http.Request, error) {
	// 多读一个字节，用它判断请求体是否超过上限，避免无界缓存。
	limited := io.LimitReader(r.Body, limit+1)
	data, err := io.ReadAll(limited)
	if err != nil {
		return nil, nil, fmt.Errorf("读取请求体失败: %w", err)
	}
	_ = r.Body.Close() // 原流只负责把字节读出来，后续改用独立读取器。
	if int64(len(data)) > limit {
		return nil, nil, fmt.Errorf("请求体超过 %d 字节限制", limit)
	}

	// 原请求和克隆请求各自拥有一个游标，不再共享 Body 状态。
	r.Body = io.NopCloser(bytes.NewReader(data))
	clone := r.Clone(r.Context())
	clone.Body = io.NopCloser(bytes.NewReader(data))
	return data, clone, nil
}

这里的关键不是 Clone 本身，而是最后两次 bytes.NewReader(data)。它们读取同一份不可变字节，但游标各自独立；如果只给 clone.Body 赋回原来的 r.Body，问题仍然存在。

出站请求优先利用 GetBody

如果请求由 http.NewRequest 根据 *bytes.Reader、*bytes.Buffer 或 *strings.Reader 创建，Go 可能为它设置 GetBody。这个函数的意义是“重新生成一份 Body”，很适合重试或需要多次发送的出站请求：

req, err := http.NewRequest("POST", "https://api.example.test/events", bytes.NewReader(payload))
if err != nil {
	return err
}

// 每次发送前都重新取得独立 Body，不能复用已经读过的 req.Body。
if req.GetBody == nil {
	return fmt.Errorf("请求体不可回放，不能直接重试")
}
body, err := req.GetBody()
if err != nil {
	return fmt.Errorf("重新创建请求体失败: %w", err)
}
retryReq := req.Clone(context.Background())
retryReq.Body = body
defer retryReq.Body.Close() // 发送完成后释放本次重建的读取器。

resp, err := http.DefaultClient.Do(retryReq)
if err != nil {
	return err
}
defer resp.Body.Close() // 响应体同样由调用方负责关闭。

GetBody 不是所有请求都有：当 Body 来自不可回放的网络流、管道或自定义读取器时，它可能为 nil。这时不能假设重试安全，应回到“先缓存、再重建”的方案，或者让上游提供可重复读取的数据源。

把内存、关闭和并发边界说清楚

最小验证可以同时检查两份内容是否相等、读取器是否独立，并确保每个新建的 Body 都由拥有它的请求负责关闭。不要在多个 goroutine 中同时消费同一个 io.ReadCloser，也不要把“第二次读到空字符串”误判为服务端没有发送数据。

相关问题

Clone 会不会复制请求体的字节？

不会。官方文档只保证请求结构的深复制，并明确说明 Body 是浅复制。需要独立读取位置时，必须自己缓存并创建新的 Reader。

为什么 NewRequest 的 GetBody 有时是 nil？

只有底层输入可以被 Go 重新定位或重新构造时才容易自动提供 GetBody。自定义流、网络流和管道没有天然的回放来源，因此应由业务代码管理缓存或重新打开逻辑。

只复制 Body 不复制 Header 可以吗？

可以，但要明确目的。若还需要修改 context、URL 或 Header，应先调用 Clone，再分别替换 Body；如果只是读取同一份数据，独立 Reader 才是决定性步骤。

小结：Request.Clone 解决的是请求结构和上下文的复制，不负责复制流内容。把 Body 看成一次性游标，先限制读取并保存字节，再为每个消费者建立独立读取器，重复读取、审计、转发和重试就能落在可控的生命周期上。