Go http.Request.Clone 和 WithContext 有什么区别：请求体、Header 与重试边界

线上接口偶发超时后，重试代码最容易踩的坑不是循环次数，而是“复制出来的请求到底共享了什么”。WithContext 适合只替换上下文的简单场景；需要准备下一次发送、修改 Header 或并发使用时，应优先考虑 Clone，但请求体仍然要按可重放规则处理。

先做一个能验证的重试小场景

假设客户端向 /v1/orders 发送 JSON，第一次请求因网关超时，第二次请求需要带上新的 trace 标识。我们关心三件事：第一，新的 Context 是否真的生效；第二，修改 Header 会不会污染原请求；第三，Body 还能不能从头读取。

req, err := http.NewRequest("POST", endpoint, bytes.NewReader(payload))
if err != nil {
    return err
}
req.Header.Set("Content-Type", "application/json")
req = req.WithContext(ctx)

这段代码没有错，但它只解决了上下文替换。不要把“返回了一个新指针”理解成所有字段都已深复制。

WithContext 和 Clone 的复制边界

WithContext 会浅复制请求结构，并把 Context 换成传入的值。它适合把请求交给另一个调用链，或者在开始发送前替换取消信号。官方文档也明确建议：如果需要深复制请求，应使用 Clone。

Clone 会复制 Header、Trailer、URL 和其他可变字段，因此更适合“基于同一份请求准备一个新版本”的场景。不过 Body 是一个流，复制结构并不会凭空复制流中的字节。两个请求若同时读取同一个 Body，结果仍然不可控。

retryReq := req.Clone(retryCtx)
retryReq.Header = retryReq.Header.Clone()
retryReq.Header.Set("X-Retry", "1")

这里再次调用 Header.Clone 是为了把意图写清楚，也方便后续维护者看到“重试请求可以独立改头部”。真正的关键仍在请求体。

带请求体的重试，先确认能不能重放

由 http.NewRequest 配合 *bytes.Reader、*strings.Reader 或 *bytes.Buffer 创建请求时，标准库通常可以设置 GetBody。但如果 Body 来自网络管道、文件流或自定义 Reader，就不能假设它支持重放。

for attempt := 0; attempt  0 {
        if req.GetBody == nil {
            return fmt.Errorf("request body is not replayable")
        }
        body, err := req.GetBody()
        if err != nil {
            return err
        }
        current.Body = body
        current.Header.Set("X-Retry", strconv.Itoa(attempt))
    }

    resp, err := client.Do(current)
    if err == nil {
        return resp, nil
    }
    if ctx.Err() != nil {
        return nil, ctx.Err()
    }
}

这段示例把“准备新请求”和“重建请求体”分开了。若第一次发送已经消费了 Body，下一次不能只调用 Clone；必须通过 GetBody 得到新的 Reader，并在失败分支里关闭已经拿到的响应体。

几个看似能用、实际不稳的写法

只调用 WithContext 后修改 Header

浅复制下，Header 可能仍与原请求共享底层数据。单线程、只读 Header 时问题不明显，一旦多个 goroutine 同时改动，就会出现数据竞争或请求间串值。重试场景应使用 Clone，并给每次发送写入独立 Header。

把 Body 字节读出来再复用同一个 Reader

Reader 的当前位置会推进。第一次请求读完后，第二次拿到的可能是空内容。缓存原始字节并用 bytes.NewReader 重新构造，或者使用可靠的 GetBody，不要把已经消费的 Reader 当作模板。

收到响应后直接继续下一次

失败重试也要关闭响应体。对同一客户端来说，及时关闭能让连接复用和资源回收更可控；如果业务需要读取错误响应，先读取必要信息，再执行 Close。

把复制边界放进测试验收

可以写一组小测试验证三条边界：修改克隆请求的 Header 不改变原请求；第二次 Body 字节与第一次一致；父 Context 取消后不会继续发起下一次请求。

if got := string(secondBody); got != string(payload) {
    t.Fatalf("retry body = %q, want original payload", got)
}
if req.Header.Get("X-Retry") != "" {
    t.Fatal("original request header was mutated")
}

测试不要只断言“最终返回成功”。把请求次数、每次收到的 Body、取消后是否还有新请求都记录下来，才能抓住重试代码里的共享状态问题。

相关问题

Clone 会复制请求体吗？

不会把流内容复制成另一份可独立读取的 Body。需要重试时，应使用可重放的 GetBody 或自行从原始字节重建 Reader。

什么时候只用 WithContext？

当请求字段不会被并发修改，只需要把取消或超时信号传到下游时可以使用。只要要改 Header、URL 或准备并行请求，就应重新评估复制方式。

重试一定要用 Clone 吗？

不一定。若每次都从原始参数重新调用 http.NewRequest，可以直接得到全新的请求；Clone 更适合保留一份已构造请求的字段，同时为本次发送建立独立副本。

小结

WithContext 解决的是上下文替换，Clone 解决的是请求结构中可变字段的复制；两者都不能自动让流式 Body 变成可重放数据。把 Header 隔离、Body 重建、响应关闭和取消检查一起写进测试，重试逻辑才算真正可验收。