Go http.Request.Clone 如何安全派生请求：Header、Body 与取消信号的边界

做 HTTP 转发时，最容易留下的隐患不是 URL 写错，而是把原请求直接改掉：上游重试改了 Header，另一个分支读到同一份 Body，超时取消却没有传到派生请求。http.Request.Clone 适合处理这种“保留原请求、派生一个新请求”的场景，但它并不是所有字段都深拷贝。

先把 Request.Clone 放进一次真实转发

假设网关收到 /orders 请求，需要带上内部追踪头转发给库存服务。原请求还要留给日志中间件读取，所以不应该直接写 r.Header。下面的函数只改派生对象：

func forward(ctx context.Context, r *http.Request) (*http.Request, error) {
    next := r.Clone(ctx)
    next.URL.Path = "/internal" + r.URL.Path
    next.Header.Set("X-Trace-Stage", "inventory")
    return next, nil
}

这里的关键不是代码短，而是职责清楚：ctx 决定派生请求的生命周期，next 承担转发字段，r 保持原样。传入 nil 会直接触发参数错误，因此上层应当把 context.Background() 或请求自身的 context 传下来，而不是用 nil 占位。

Header 和 URL 为什么能放心修改

Clone 的价值在于它会复制请求中多数可变结构。派生请求执行 Header.Set、调整 URL 查询参数或修改 Trailer 时，通常不会直接改掉原请求对应的 map 和 URL 对象。这个隔离适合给重试、鉴权或内部路由添加一次性字段。

不过，“能改”不等于“可以随便共享”。如果代码把派生请求里的 Header map 再次交给多个 goroutine 写，仍然会遇到并发 map 写入问题。每个分支应拥有自己的派生请求，并在发送前完成字段设置。

Body 是浅拷贝，重试前必须先处理读取位置

Body 是这件事里最容易误判的字段。第一次发送会消耗读取流；即使调用了 Clone，第二个请求也不会凭空得到一份新的字节流。对于小型 JSON 请求，可以在入口一次性读取，再用 io.NopCloser(bytes.NewReader(payload)) 给每个派生请求创建新的 Body：

payload, err := io.ReadAll(r.Body)
if err != nil {
    return err
}

makeRequest := func(ctx context.Context) *http.Request {
    next := r.Clone(ctx)
    next.Body = io.NopCloser(bytes.NewReader(payload))
    next.ContentLength = int64(len(payload))
    return next
}

大文件上传不适合无条件读入内存。更稳妥的做法是让上层提供可重新打开的文件或实现 GetBody，并给重试设置次数、大小和总耗时上限。否则一次网络抖动就可能把内存和磁盘都拖进异常路径。

把取消信号传到真正发请求的地方

如果转发使用的是 http.Client.Do(next)，派生请求携带的 context 会影响建连、发送请求和读取响应头。常见的错误是只给外层函数加了超时，却继续拿原请求去调用客户端，导致取消信号没有覆盖实际网络操作。

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

next := r.Clone(ctx)
next.Header.Set("X-Trace-Stage", "inventory")
resp, err := client.Do(next)
if err != nil {
    return err
}
defer resp.Body.Close()

检查点有两个：一是 next.Context() 是否就是本次超时 context，二是下游收到取消后，调用方是否确实停止等待。不要把“函数返回了”误当成“下游已经完成”；日志里应记录超时原因和请求阶段，便于区分连接失败、服务端响应慢和客户端主动取消。

相关问题：四个边界怎么判断

Request.Clone 和 WithContext 该怎么选？

只想替换 context 且不会修改其他请求字段时，WithContext 足够；要给 Header、URL、Trailer 等派生对象做独立修改，优先使用 Clone。

Clone 后能不能安全重发 Body？

不能直接假设可以。Body 仍是浅拷贝，重发前应准备新的 Reader、可重开的文件或可靠的 GetBody。

为什么 Header 改了原请求却没变？

因为 Clone 会复制 Header 结构。若仍看到原请求变化，通常是代码在 Clone 前修改了原对象，或把某个 Header 值引用到外部共享结构。

context.WithTimeout 到期后还要主动关闭响应吗？

只要已经拿到响应，就应按正常路径关闭 resp.Body；context 负责取消请求生命周期，不替代响应资源清理。

落地前的最小核对

把转发代码合入服务前，至少做一次 Header 隔离、Body 重读和超时取消测试。测试里不要只断言返回 error，还要确认原请求 Header 未被污染、每次发送读到完整 Body，并能在超时预算内结束。这样才能把 Clone 的“复制请求”理解成可验证的边界，而不是一个万能深拷贝按钮。