Go json.Decoder遇到空输入返回EOF的判断方法

很多Gopher在使用Go标准库的`json.Decoder`解析请求或者输入流的时候，经常会碰到传入空内容直接返回EOF错误的情况，要是直接把这个错误当成JSON格式异常处理，很容易误拦截合法的空输入场景，你可以通过标准库提供的错误判断逻辑，精准把空输入触发的EOF和其他真正的解析错误区分开。

碰到空输入场景下`Decoder.Decode()`返回的`io.EOF`，我们只需要判断目标对象还没有写入任何字段、同时返回的错误恰好是`io.EOF`，就可以判定这是合法的空输入，不用把它当成解析异常抛出。

调用 json.Decoder.Decode 读取空字符串、只有空白的响应，或者已经读完的 JSON 流时，返回 io.EOF 是正常行为。它表示“这次没有下一个 JSON 值”，不等于 JSON 一定损坏。真正需要区分的是：EOF 发生在第一个值之前，还是发生在已经成功读取若干值之后；如果输入只写了一半，通常应该按截断输入或语法错误处理。

Decode 返回 EOF 前到底发生了什么

NewDecoder 会围绕 io.Reader 建立自己的缓冲，并按 JSON 值读取。每次 Decode 只负责取下一个值；当输入中已经没有值时，返回 io.EOF。所以空输入、空白输入，以及连续对象全部处理完后的下一次读取，都会出现这个结果。

判断重点不是“有没有错误”，而是“这次有没有读到值”。下面的循环适合处理一组连续 JSON 值，例如按换行传输的对象流：

package main

import (
    "encoding/json"
    "errors"
    "fmt"
    "io"
    "strings"
)

type Event struct {
    ID   string `json:"id"`
    Type string `json:"type"`
}

func decodeEvents(input string) ([]Event, error) {
    dec := json.NewDecoder(strings.NewReader(input))
    events := make([]Event, 0, 4)

    for {
        var event Event
        err := dec.Decode(&event)
        switch {
        case err == io.EOF:
            // 没有下一个 JSON 值：空输入或数据流自然结束。
            return events, nil
        case err != nil:
            // 截断和语法错误必须保留上下文，不能伪装成正常结束。
            var syntaxErr *json.SyntaxError
            if errors.Is(err, io.ErrUnexpectedEOF) || errors.As(err, &syntaxErr) {
                return nil, fmt.Errorf("JSON 输入不完整或非法: %w", err)
            }
            return nil, fmt.Errorf("解码事件失败: %w", err)
        default:
            // 只有 Decode 成功后才把目标对象加入结果。
            events = append(events, event)
        }
    }
}

这里的 EOF 分支只说明“没有下一个值”，并不说明结果一定应该被业务接受。decodeEvents("") 可以得到空切片；如果上游契约要求至少返回一个事件，调用方还要在结果长度为零时单独报业务错误。

用读取次数判断 EOF 是否可接受

如果文章标题中的“空输入”来自 HTTP 接口，最容易踩的坑是把空响应当成成功响应。可以让解码函数显式返回 found，把传输层的 EOF 与业务层的“必须有对象”分开：

func decodeOne(input string) (Event, bool, error) {
    dec := json.NewDecoder(strings.NewReader(input))
    var event Event
    err := dec.Decode(&event)
    switch {
    case err == io.EOF:
        // 第一个值就不存在：由调用方决定是否允许空响应。
        return Event{}, false, nil
    case err != nil:
        // 非 EOF 错误不能当作“没有数据”，否则会吞掉坏 JSON。
        return Event{}, false, fmt.Errorf("读取首个事件失败: %w", err)
    default:
        // found=true 表示已经成功获得一个完整 JSON 值。
        return event, true, nil
    }
}

func requireEvent(input string) (Event, error) {
    event, found, err := decodeOne(input)
    if err != nil {
        return Event{}, err
    }
    if !found {
        // 业务要求必须有对象时，把空输入转换为领域错误。
        return Event{}, errors.New("响应中没有事件对象")
    }
    return event, nil
}

可以把判断整理成下面的清单。它比单纯写 if err == io.EOF { return nil } 更安全，因为它把业务契约也纳入了决策。

如果需要知道错误位置，可以用 errors.As 提取 *json.SyntaxError；如果输入来自长连接或文件，建议同时记录已经成功解码的数量。这样日志能回答“坏数据出现在第一个对象前，还是第 N 个对象后”，比只打印 EOF 更有用。

四组输入组成最小回归检查

修改判断逻辑后，至少覆盖四组样例："" 或 " " 验证空输入；两个连续对象验证循环结束；{"id": 验证截断；{"id" "x"} 验证语法错误。测试关注点是返回值、错误类型和已经成功保存的对象数量，而不是把所有错误都比较成一段字符串。

还有一个边界：Decode 成功只代表 JSON 能映射到目标值，不代表字段满足业务要求。若 id 为空、事件类型不允许，应该在解码成功后做领域校验。这样，io.EOF 负责流边界，JSON 错误负责格式，业务错误负责内容，三层职责不会互相覆盖。

延伸问答

空输入和空 JSON 对象是不是一回事？

不是。空输入没有 JSON 值，通常返回 io.EOF；{} 是一个完整对象，Decode 会成功，但目标结构体可能仍然是零值。

为什么不能把所有 EOF 都记录成错误？

流式读取在自然结束时本来就会返回 io.EOF。只有当接口契约要求至少一个值时，首次 EOF 才需要转换为业务错误。

读取到半个 JSON 时应该重试吗？

先确认上游是否提前关闭、响应是否被截断以及传输是否支持重试。io.ErrUnexpectedEOF 不是“没有数据”的同义词，不能直接按空结果继续。