Go http.Request.Write 怎样把请求写成 HTTP 报文

想观察一个 http.Request 最终会被写成什么样的 HTTP/1.1 报文，可以调用 Request.Write，把输出交给任意 io.Writer，例如 bytes.Buffer。它负责写出请求行、请求头和请求体；Host、Content-Length、Transfer-Encoding 等关键字段会根据 Request 的结构化字段重新计算。

官方地址：https://pkg.go.dev/net/http@go1.27.3#Request.Write

Request.Write 适合生成发往 HTTP 服务端的普通请求报文。若目标是 HTTP 代理，应使用 Request.WriteProxy，因为它会把请求行中的 Request-URI 写成包含 scheme 和 host 的绝对 URI。

Request.Write 真正写出哪些字段

官方文档列出的核心输入包括 Host、URL、Method、Header、ContentLength、TransferEncoding 和 Body。Method 为空时按 GET 处理；如果没有显式的 User-Agent，输出会补上 Go-http-client/1.1。不要试图直接在 Header 中伪造 Content-Length 或 Transfer-Encoding，写出时这些值以 Request 字段为准。

用 bytes.Buffer 接住完整请求报文

下面的例子构造一个带 JSON 请求体的 POST 请求，并将结果写入缓冲区。示例只展示序列化边界，不会发送网络请求，因此适合做协议调试、签名预览或自定义传输层的输入准备。

package main

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

func main() {
    body := strings.NewReader(`{"name":"gopher"}`)
    req, err := http.NewRequest("POST", "http://api.example.test/users", body)
    if err != nil {
        // URL 或请求方法非法时，不能继续写出不完整的 Request。
        panic(err)
    }
    req.Header.Set("Content-Type", "application/json")

    var wire bytes.Buffer
    // Write 只写入目标 Writer，不会替代 Client.Do 发送请求。
    if err := req.Write(&wire); err != nil {
        // 写入失败可能来自目标 Writer 或请求字段，必须保留错误。
        panic(err)
    }
    fmt.Print(wire.String())
}

对于这个请求，报文的第一行是相对路径形式的 POST /users HTTP/1.1，并带有 Host、Content-Type、Content-Length 等字段。NewRequest 能识别 *strings.Reader 的长度，所以可以设置精确的 Content-Length；如果 Body 存在但长度未知且未指定 identity，Write 会选择 chunked 传输。

请求体关闭和长度边界要一起处理

Request.Write 在请求体发送完成后会关闭 Body。调用方仍应处理返回错误，因为目标 Writer 可能提前失败，Body 读取也可能返回错误。若要重复写同一个请求，不要假设原 Body 仍可从开头读取；应使用可重放的 Reader，或在业务层重新创建 Request。

• 已知长度：ContentLength 为非负值时，优先写出 Content-Length。
• 未知长度：Body 存在、长度不确定且没有 identity 时，通常使用 Transfer-Encoding: chunked。
• 禁止伪造：Header 中手工写入的 Host、Content-Length、Transfer-Encoding 和 Trailer 不会覆盖结构化字段。
• 生命周期：Body 写完会关闭，若复用请求，先明确是否能重新提供相同字节流。

普通请求和代理请求不要混用

Request.Write 面向直接发送给 HTTP 服务端的请求，写出的请求行使用相对 Request-URI；Request.WriteProxy 面向代理，写出的请求行会使用包含 scheme 和 host 的绝对 URI，并同样写出 Host。两者都写 HTTP/1.x 报文，但请求目标格式不同。

因此，若你只是把请求交给自定义 TCP 连接并直连目标服务，优先使用 Write；若连接的另一端按 HTTP 代理协议等待完整 URL，再选择 WriteProxy。不要通过改写字符串来“补全”请求行，否则容易让 URL、Host 和代理路由出现不一致。

常见问题

Request.Write 会发出网络请求吗？

不会。它只把报文写到传入的 io.Writer；真正的连接、重试和响应处理属于 http.Client 或 Transport。

为什么 Header 里的 Content-Length 没生效？

Content-Length 由 Request.ContentLength 和 Body 状态推导。需要控制长度时应设置结构化字段并保证 Body 与长度一致，不要只修改 Header。

什么时候用 WriteProxy？

当写出的下一跳是 HTTP 代理、并且代理需要绝对 URI 请求目标时使用；直连服务端时使用普通的 Write。

可以把 Request.Write 记成“Request 到 HTTP/1.1 字节流的序列化边界”：结构化字段决定报文，Body 决定内容与生命周期，目标是直连服务端还是代理则决定请求行格式。把这三层分开，调试报文时就不容易被 Header 表面值误导。