Go net/http NewRequest 如何区分空 body 和零长度 body

调用 http.NewRequest 时，ContentLength == 0 不能单独证明“没有请求体”。它既可能来自 body == nil 或 http.NoBody，也可能只是一个普通 io.Reader 的长度未知。实际判断要把 Request.Body、Request.ContentLength 和 Request.GetBody 放在一起看；如果还要区分调用者传入的 Reader 类型，则必须在进入 NewRequest 前保留输入信息。

官方资料：https://pkg.go.dev/net/http　源码：https://go.dev/src/net/http/request.go

四种输入为什么得到不同的 Request 字段

NewRequest 先把非空且不是 io.ReadCloser 的 Reader 包成可关闭对象，然后只对三类具体 Reader 做额外识别：*bytes.Buffer、*bytes.Reader 和 *strings.Reader。因此“空 body”和“读取后暂时没有字节”在构造阶段不是同一个概念。

NewRequest 如何识别已知长度 Reader

源码对三类 Reader 读取当前剩余长度，并为它们生成 GetBody。这解释了两个常见现象：一是空的字符串或字节 Reader 最终看到的是 http.NoBody；二是请求在 307/308 重定向等需要重新发送时，客户端有机会从 GetBody 获取一份新的读取对象。

下面的示例只检查构造后的字段，不依赖发送请求。它把“明确无 body”“已知零长度”和“未知长度”分开打印：

package main

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

// zeroReader 模拟一个无法提前提供长度的 Reader。
type zeroReader struct{}

func (zeroReader) Read([]byte) (int, error) { return 0, io.EOF }

// report 只观察 NewRequest 产出的字段，不发起网络请求。
func report(name string, body io.Reader) {
    req, err := http.NewRequest(http.MethodPost, "https://api.example.com/items", body)
    if err != nil {
        fmt.Println(name, "error:", err)
        return
    }
    fmt.Printf("%-20s BodyNil=%t NoBody=%t ContentLength=%d GetBody=%t\n",
        name, req.Body == nil, req.Body == http.NoBody, req.ContentLength, req.GetBody != nil)
}

func main() {
    report("nil", nil)
    report("NoBody", http.NoBody)
    report("empty bytes", bytes.NewReader(nil))
    report("empty string", strings.NewReader(""))
    report("custom reader", zeroReader{})
}

判断重点不在 Body 的具体内部类型，而在三个稳定信号：Body == nil 表示没有对象；Body == http.NoBody 表示 HTTP 层采用无 body 哨兵；GetBody != nil 通常说明构造器掌握了这类 Reader 的可重建方式。

不要把 ContentLength=0 当成唯一结论

Request.ContentLength 的文档已经说明，客户端请求中 0 既可能是真正的零长度，也可能是未知长度。普通 Reader 被 io.NopCloser 包装后，构造器没有通用方法提前知道它会返回多少字节，于是不会替你生成精确的长度和 GetBody。

所以这段判断是不够的：

// 错误示例：0 同时覆盖明确无 body 和未知长度 Reader。
if req.ContentLength == 0 {
    fmt.Println("没有请求体")
}

更稳妥的做法是把“发送策略”和“输入分类”分开：

// classify 先判断明确的哨兵，再把长度 0 留给后续策略处理。
func classify(req *http.Request) string {
    if req.Body == nil || req.Body == http.NoBody {
        return "explicitly-empty"
    }
    if req.GetBody != nil && req.ContentLength == 0 {
        return "known-zero-length-reader"
    }
    if req.ContentLength > 0 {
        return "known-non-empty"
    }
    return "unknown-length-reader"
}

如果业务真的要求知道长度，应在构造请求前使用 bytes.Reader、strings.Reader 或 bytes.Buffer，或者由业务层单独记录长度。不要为了“修正”字段而随意手写 ContentLength，因为声明值与实际可读字节不一致会让发送端和服务端产生更难排查的问题。

发送请求前的三个检查点

第一，客户端请求用的是 net/http.NewRequest，测试服务端 Handler 则应区分 httptest.NewRequest；两者的 Body 语义不要混用。第二，若 Reader 同时实现了 io.Closer，它会成为请求的 Body，并由客户端在发送后关闭。第三，若请求可能经历重定向或重试，检查 GetBody 是否存在，而不要只看第一次读取是否成功。

• 需要明确“无 body”：传入 nil，或显式传入 http.NoBody。
• 需要表达“已知空内容”：使用空的 bytes.Reader、strings.Reader 或 bytes.Buffer，并允许 NewRequest 生成 GetBody。
• 需要流式读取：接受长度未知，把分类结果标为 unknown，不把 ContentLength=0 改写成“空”。

相关问题

为什么空 strings.Reader 的 Body 不是 nil？

为了保持请求 Body 的统一可关闭语义，NewRequest 会使用 http.NoBody 这个已知哨兵表示零长度，而不是把所有空 Reader 都变成 nil。

ContentLength 为 -1 才代表未知吗？

不能把这个结论直接套到 NewRequest 的客户端请求上。该构造器对普通 Reader 保留 0 的兼容语义，因此判断时仍应结合 Body 和 GetBody。

能不能通过读取 Body 一次来判断是否为空？

不建议只为判断而消费请求体；这样会改变后续发送内容。优先在构造前保留 Reader 类型，或使用可重建的 bytes/strings Reader。

服务端收到的 Request 也按这套规则判断吗？

不应直接照搬。服务端请求经过解析，ContentLength、TransferEncoding 和 Body 的含义由收到的 HTTP 报文决定；本文结论限定在客户端调用 net/http.NewRequest 的构造阶段。