Go 问答：net/http Request.Clone 会复制哪些字段：Body、Header 与 Context 的独立性

给 HTTP 请求加重试或同时发给两个下游时，直接复用同一个 *http.Request 很容易把 Header、Context 和请求体的状态搅在一起。Request.Clone 能复制请求的大部分结构，但它不是“把 Body 倒回起点”的万能复制器：Body 的读取位置仍要靠 GetBody 或重新准备输入。

可以把 Request.Clone 当成请求元数据和取消链的独立副本；如果要再次发送同一份请求体，必须另外确认 Body 可重建，不能只调用 Clone。

重试现场：为什么第二次请求变成空请求体

一个 webhook 接收器先把请求转发给风控服务，风控返回临时错误后再转发一次。第一次尝试如果已经读取了 Body，随后写下这句代码：

retry := req.Clone(ctx)
resp, err := client.Do(retry)

第二次请求的 Header 看起来正常，Context 也能响应取消，但服务端收到的 Body 可能已经没有内容。问题不在 Clone 失效，而在 io.ReadCloser 是一次性读取流：复制 Request 结构，不等于复制流当前位置之后的数据。

Request.Clone 到底复制了哪些请求状态

官方文档把 Clone 描述为返回请求的深拷贝，但文档同时明确指出：对于 Body，深拷贝只适用于已知可复制的请求结构，不能把一个任意读取器的内部游标凭空复原。实际使用时可以按三组来记。

Header 和 URL 适合按副本修改

克隆后修改 retry.Header 或 retry.URL，不会直接改掉原请求对应的 map 和 URL 结构。比如重试时追加一个稳定的请求标识：

retry := req.Clone(ctx)
retry.Header = retry.Header.Clone()
retry.Header.Set("X-Retry", "1")
retry.URL.Path = "/v2/verify"

这里的意图是让重试请求拥有自己的元数据。Header 的值切片也需要通过 Header.Clone 获得独立副本，避免后续 Add 操作与原请求共享底层数组。

Context 会切换到 Clone 的入参

req.Clone(ctx) 使用传入的 ctx 作为新请求的 Context。下游请求超时通常应该为每次尝试创建独立的子 Context，但所有子 Context 都应挂在上层请求的取消链上：

attemptCtx, cancel := context.WithTimeout(ctx, 800*time.Millisecond)
defer cancel()

retry := req.Clone(attemptCtx)
resp, err := client.Do(retry)

当上游取消 ctx 时，attemptCtx 会一起结束；如果只是某一次尝试超时，调用该次的 cancel 不会改变原请求的 Context。

Body 的正确重试方式：GetBody 或缓存原始字节

最稳妥的做法是在创建请求时保留可重建入口。由 http.NewRequest 配合 *bytes.Reader、*bytes.Buffer 或 *strings.Reader 创建请求时，标准库通常可以填充 GetBody：

payload := []byte(`{"event":"paid","id":"a17"}`)
req, err := http.NewRequest("POST", endpoint, bytes.NewReader(payload))
if err != nil {
    return err
}

body, err := req.GetBody()
if err != nil {
    return err
}
retry := req.Clone(ctx)
retry.Body = body
resp, err := client.Do(retry)

如果 Body 来自管道、压缩流或自定义 Reader，GetBody 可能为空。这时应在业务层保存原始字节，或者明确规定该请求不可自动重试。不要为了“重置”而强行读取未知流，那会增加内存占用，也可能改变上传语义。

旧写法的兼容边界与迁移检查

只给 Header 换一个值、只调整 URL 的重试，可以直接使用 Clone；带 JSON、表单或文件流的请求，要先确认 Body 的重建策略。代码审查时我会逐项核对：

• 是否在第一次 Do 前就保存了 GetBody 或原始 payload。
• 重试是否使用新的超时 Context，而不是复用已经结束的 Context。
• 是否只修改 Clone 后的 Header、URL 和请求专属字段。
• 非幂等 POST 是否有幂等键、服务端去重或明确的“不自动重试”规则。

用最小测试确认复制边界

不要只检查两个指针地址。测试应验证三件事：克隆后的 Header 修改不影响原请求；传入的新 Context 能被读取；Body 在第一次读取后是否仍能通过 GetBody 获得完整内容。

func TestCloneBoundaries(t *testing.T) {
    payload := []byte("hello")
    req, err := http.NewRequest("POST", "https://example.test/hook", bytes.NewReader(payload))
    if err != nil {
        t.Fatal(err)
    }
    req.Header.Set("X-Trace", "origin")

    ctx, cancel := context.WithCancel(context.Background())
    defer cancel()
    clone := req.Clone(ctx)
    clone.Header.Set("X-Trace", "retry")

    if req.Header.Get("X-Trace") != "origin" {
        t.Fatal("original Header changed")
    }
    body, err := clone.GetBody()
    if err != nil {
        t.Fatal(err)
    }
    got, err := io.ReadAll(body)
    if err != nil {
        t.Fatal(err)
    }
    if string(got) != string(payload) {
        t.Fatalf("body = %q", got)
    }
}

如果测试中的 Body 是自定义流，就把“可重建”作为显式接口能力测试，而不是假设 Clone 能替你保存数据。

相关问题：三个容易混淆的判断

Clone 能不能让原请求重复发送？

不能单独保证。它复制请求结构；重复发送还要求 Body 能通过 GetBody 或业务缓存重新得到。

Clone 后修改 Header 会影响原请求吗？

正常的 Clone 会复制 Header 结构，但对 Header 的多值切片仍建议显式调用 Header.Clone，随后只修改副本。

每次重试都要新建 Context 吗？

通常应为每次尝试建立带超时的子 Context，并保留上游取消链；不要复用已经超时或取消的 Context。

把复制和重试拆成两个问题

Request.Clone 解决的是“请求元数据和取消链如何得到一个独立对象”，GetBody 或原始 payload 解决的是“请求体如何再次读取”。把这两件事分开检查，重试代码才不会出现 Header 已更新、Context 已切换、Body 却悄悄为空的半成功状态。