本文讲解在 Go 的 HTTP 处理器中，为何 json.Decoder.Decode 无法区分空对象 {} 与真正空的请求体，并提供可靠方案：先读取原始字节、再判断长度、最后按需反序列化。
本文讲解在 go 的 http 处理器中，为何 `json.decoder.decode` 无法区分空对象 `{}` 与真正空的请求体，并提供可靠方案：先读取原始字节、再判断长度、最后按需反序列化。
在 Go Web 开发中，一个常见误区是依赖 json.NewDecoder(r.Body).Decode() 的错误类型（如 io.EOF）来判断请求体是否为空。但需明确：io.EOF 仅在读取到流末尾且未解析出任何有效 JSON 值时触发（例如空 body "" 或纯空白），而合法的空 JSON 对象 {} 会被成功解码为零值结构体 —— 此时 err == nil，hasOpts 仍为 true，导致业务逻辑误判。
正确做法是显式读取并检查原始请求体内容，再决定是否执行 JSON 解析：
body, err := io.ReadAll(r.Body)
if err != nil {
return fmt.Errorf("failed to read request body: %w", err)
}
var opts Request
if len(body) > 0 {
if err := json.Unmarshal(body, &opts); err != nil {
return fmt.Errorf("could not parse advanced options: %w", err)
}
}
// 此时 hasOpts = len(body) > 0，语义清晰且可靠
hasOpts := len(body) > 0⚠️ 注意事项：
- 使用
io.ReadAll（Go 1.16+ 推荐）替代已弃用的ioutil.ReadAll； - 必须在
json.Unmarshal前完成r.Body读取，否则后续读取将返回空（Body是单次读取流）； - 若请求体可能较大，应添加长度限制（如
http.MaxBytesReader）防止内存耗尽； - 空字符串
""、空白符（\n\t）或无效 JSON 均会导致len(body) > 0但json.Unmarshal失败，需按需处理（例如跳过空白后判断）。
总结：JSON 解码器的设计目标是解析有效数据，而非检测“空性”。要实现语义级的“有无请求体”，必须回归字节层面对 r.Body 进行主动探测 —— 这是健壮 API 设计的必要实践。
