Go http.NewRequest 传 nil Body 后 ContentLength 为什么为零

在 Go 中执行 http.NewRequest(http.MethodPost, url, nil) 后看到 req.ContentLength == 0，这是正常结果。对出站请求来说，nil Body 表示没有请求体，ContentLength 保持零值；此时不能只凭这个数字判断“标准库已经计算出一个长度为零的 Reader”。真正要一起看的字段是 Body 和 GetBody。

nil 适合表达“没有 Body”；http.NoBody 适合明确表达“有一个已知为空的 Body”。而普通的非空 Reader 如果没有被标准库识别，ContentLength=0 还可能代表未知长度。

先把 nil Body 的三个字段放在一起看

NewRequest 接收的是 io.Reader，传入 nil 后，返回请求的 Body 仍为空，GetBody 也没有可用于重放请求体的函数。ContentLength 是 int64 字段，创建请求时未被设置就保持 0。

package main

import (
    "fmt"
    "net/http"
)

func main() {
    // nil 表示这个 POST 没有要发送的请求体。
    req, err := http.NewRequest(http.MethodPost, "https://api.example.test/ping", nil)
    if err != nil {
        panic(err)
    }

    // ContentLength=0 需要与 Body、GetBody 一起解释，不能单独下结论。
    fmt.Printf("body-nil=%v length=%d get-body-nil=%v\n",
        req.Body == nil, req.ContentLength, req.GetBody == nil)
}

这里的 0 不是“NewRequest 先读取了 nil，再得到空结果”的意思，而是一个未设置长度的零值。对客户端请求，Request 文档还规定：当 Body 非 nil 时，ContentLength=0 也可能按未知长度处理。因此排查时先看 Body 是否为 nil，再看 Reader 的具体类型。

为什么空 strings.Reader 会走另一条分支

标准库会识别三类常见 Reader：*bytes.Buffer、*bytes.Reader 和 *strings.Reader。它们能提供当前可读长度，所以 NewRequest 会填入精确的 ContentLength，并创建 GetBody 供 307、308 重定向时重放。

// 这三个请求都没有可读字节，但表达方式并不等价。
emptyText, _ := http.NewRequest(http.MethodPost, endpoint, strings.NewReader(""))
emptyBytes, _ := http.NewRequest(http.MethodPost, endpoint, bytes.NewReader(nil))
noBody, _ := http.NewRequest(http.MethodPost, endpoint, http.NoBody)

// 空的已知 Reader 会被标准库转成 NoBody；NoBody 本身用于明确表达零字节。
fmt.Println(emptyText.ContentLength, emptyText.Body == http.NoBody)
fmt.Println(emptyBytes.ContentLength, emptyBytes.Body == http.NoBody)
fmt.Println(noBody.ContentLength, noBody.Body == http.NoBody)

上面的片段需要补上 bytes、strings 和 net/http 导入。重点不是记住某个打印顺序，而是理解“可识别的空 Reader”和“nil Body”有不同的元数据：前者可能保留可重放能力，后者没有请求体，也没有 GetBody。若接口只要求一个无载荷的 POST，传 nil 通常就够了；若代码审查希望显式标注零字节，使用 http.NoBody 更直观。

非空 Body 却看到 ContentLength=0，通常是长度未知

把 Reader 包在自定义类型、io.LimitReader 或其他流式适配器后，标准库未必能在创建请求时知道剩余字节数。此时 Body != nil，但 ContentLength 仍可能为 0。它不表示请求体一定为空，Transport 会依据请求体和协议选择合适的发送方式。

不要用 Header 里的 Content-Length 代替 Request 字段

出站请求的 Content-Length、Transfer-Encoding 等头部通常由 Request 字段和 Transport 推导，直接写入 Header 并不能可靠覆盖它们。最危险的写法是给一个仍会产生未知字节数的 Body 填入错误长度，结果可能造成截断、等待或服务端解析失败。

func newJSONRequest(endpoint string, payload []byte) (*http.Request, error) {
    // bytes.Reader 提供精确长度，也让请求在需要时具备重放条件。
    req, err := http.NewRequest(http.MethodPost, endpoint, bytes.NewReader(payload))
    if err != nil {
        return nil, err
    }
    req.Header.Set("Content-Type", "application/json")
    // 不手工设置 Content-Length，让 net/http 根据 Request 字段处理。
    return req, nil
}

如果数据来自文件或实时流，不要为了让数字好看而强行填写长度；应该根据数据源是否可重复读取、服务端是否接受分块传输以及重定向策略做决定。需要重定向重放时，除了长度，还要确认 GetBody 能否重新得到同一份数据。

排查时按这张清单确认结果

1. 先确认这是客户端请求，不要把 httptest.NewRequest 的入站测试语义和 http.NewRequest 混在一起。
2. 打印或调试查看 req.Body == nil、req.ContentLength 和 req.GetBody == nil 三个状态。
3. 检查传入 Reader 的动态类型；包装层可能让标准库无法获得精确长度。
4. 需要真实长度时使用可识别的内存 Reader，或由业务层依据可信数据源维护长度，不要复制到 Header。
5. 有 307、308 重定向时，单独验证 Body 是否可重放；没有 GetBody 的流式请求不能假设能自动重发。

相关问题

ContentLength 为 0 就一定不会发送请求体吗？

不一定。若 Body 为 nil，表示没有请求体；若 Body 非 nil，零值还可能表示未知长度，必须继续看 Reader 和传输语义。

空字符串应该传 nil 还是 strings.NewReader("")？

若业务语义是“没有请求体”，传 nil；若要保留一个显式的空 Reader 语义，可以传空 Reader。两者都可能发送零字节，但字段和重放元数据不同。

什么时候使用 http.NoBody？

当代码需要明确表达“请求体存在于接口模型中，但确定没有任何字节”时使用。它比依赖某个空 Reader 的具体类型更容易读懂。

为什么自定义 Reader 的 ContentLength 不能自动算出来？

io.Reader 只保证按需读取，不保证能提前知道总长度。除非类型提供了可识别的长度信息，否则创建请求时只能保留未知边界。

参考：net/http.NewRequestWithContext、net/http.Request、Go 官方 request.go 源码。