Go json.Decoder 为什么第二次 Decode 会得到 EOF：请求体读取、空白与流式边界

接口已经正常读出了一个 JSON 对象，代码执行第二次 Decode 却返回 io.EOF，这基本都不是请求调用失败，而是输入流按照逻辑走到了末尾。先理清楚你当前的接口约定是只接受单个 JSON 文档，还是允许同一个输入流里连续存放多个 JSON 值。前者场景下第二次读取应当作尾部合法性校验的步骤，后者场景下才需要继续循环做解码操作。

单对象请求第一次 Decode 成功、第二次 Decode 得到 EOF 时，通常表示正文已经完整读完；只有协议明确允许多个 JSON 值连续传输时，才可以直接把 EOF 当作循环读取的退出条件。

先把请求体分成三种输入场景

下面三段正文看起来都符合 JSON 格式，但服务端需要采取完全不同的处理策略：

{"name":"Ada"}

{"name":"Ada"} {"name":"Lin"}

{"name":"Ada"} garbage

第一种是单个 JSON 文档，末尾可能带换行、空格这类空白字符；第二种是两个连续拼接的 JSON 值；第三种则是在第一个合法值后面混入了非法内容。如果只调用一次 Decode，三者都会正常返回第一个对象，后续的差异点全部被留在了输入流的尾部。

单对象接口的最小读取流程

对于 POST /profile 这类只接受单个对象的普通接口，可以先解码一次拿到目标对象，再用第二次解码做尾部校验：

type Profile struct {
    Name string json:"name"
}

func readOne(body io.Reader) (Profile, error) {
    var in Profile
    dec := json.NewDecoder(body)
    if err := dec.Decode(&in); err != nil {
        return Profile{}, fmt.Errorf("read profile: %w", err)
    }

    var extra any
    err := dec.Decode(&extra)
    if errors.Is(err, io.EOF) {
        return in, nil
    }
    if err == nil {
        return Profile{}, fmt.Errorf("request contains more than one JSON value")
    }
    return Profile{}, fmt.Errorf("invalid trailing data: %w", err)
}

这里第二次读取拿到的 EOF，含义是流里没有下一个 JSON 值。它不是第一步解码失败，也不是需要把 EOF 直接返回给客户端的错误。真正需要拦截的请求错误包括第一步就无法解析出合法对象、第二步读到了第二个额外对象，或者尾部出现了破损的非法字符。

为什么只 Decode 一次不够严谨

如果只调用一次 Decode，服务端会在解析完第一个对象后直接返回成功。这种逻辑下，两个连续拼接的 JSON 对象也可能被当作合法的单对象请求处理。第二次读取的作用，正是把「解析出一个合法值」和「整个正文符合约定」这两个判断拆开校验。

不要用 dec.More() 方法来判断顶层是否还有第二个 JSON 值。More 方法主要是服务于数组或对象内部遍历下一个元素的判断；要做顶层正文的结束校验，直接执行下一次 Decode 逻辑会更清晰直观。

允许多值流场景下，EOF 才是合法的循环出口

如果输入确实是连续流式场景，比如数据管道里依次送入多个独立对象，那么读取函数的逻辑必须明确匹配这个协议约定：

func readStream(body io.Reader) ([]Profile, error) {
    dec := json.NewDecoder(body)
    var all []Profile
    for {
        var item Profile
        err := dec.Decode(&item)
        if errors.Is(err, io.EOF) {
            return all, nil
        }
        if err != nil {
            return nil, fmt.Errorf("read stream item %d: %w", len(all), err)
        }
        all = append(all, item)
    }
}

这类场景下一定要补上元素数量上限、单项大小限制和错误位置记录逻辑。否则对端持续发送数据时，存储结果的切片会无限制增长；如果是对外的 HTTP 接口，还要在协议文档里写清楚它是连续 JSON 流还是单个 JSON 数组。绝大多数普通批量接口更适合直接接收一个 JSON 数组，同时对数组长度做明确限制。

请求体验证的几个边界场景

空正文和全空白正文

第一次 Decode 就直接返回 io.EOF，说明没有读到任何有效 JSON 值。空正文和「第一次成功、第二次 EOF」不是同一种情况，前者通常应该直接返回参数缺失错误。

尾部是合法值还是非法字节

第二次 Decode 返回 nil，说明后面还有另一个完整的 JSON 值；第二次返回语法错误，说明第一个值后面存在不完整或者非法的字符。这两种情况都不应该静默保留第一个对象就直接放行。

类型检查和未知字段拦截

json.Decoder 默认会忽略结构体里没有声明的字段。如果接口需要拒绝拼写错误或者未约定的字段，可以在第一次 Decode 前调用 DisallowUnknownFields 方法，但要提前确认这个调整不会影响存量客户端的兼容性。

把读取逻辑放进可复查的单元测试

不要只测试正常的合法对象场景。至少把空正文、尾随空白、第二个额外对象、非法尾部这几类场景放到表格驱动测试用例里：

tests := []struct {
    name string
    body string
    wantErr bool
}{
    {"one value", "{"name":"Ada"}", false},
    {"trailing spaces", "{"name":"Ada"}  
", false},
    {"two values", "{"name":"Ada"}{"name":"Lin"}", true},
    {"broken tail", "{"name":"Ada"}oops", true},
    {"empty", "", true},
}

测试的核心不是断言错误字符串完全匹配，而是确认合法单对象能正常保存、尾随空白能正常兼容、额外值会被直接拒绝、首个对象后面的坏数据不会被静默吞掉。如果当前函数还负责限制正文大小，再补充超过大小限制的 Reader 测试场景。

常见误区与上线前速查

• 不要把第二次校验得到的 EOF 包装成数据库错误；它只是本次检查得出的流结束标识。
• 不要为了消掉 EOF 就无条件重试 Decode；没有更多可读字节时重试也不会产生新的 JSON 值。
• 不要只验证完第一个对象就给严格单对象接口直接放行；尾部检查决定了整个正文是否符合约定。
• 不要把 JSON Lines、连续独立 JSON 值和 JSON 数组这三种不同协议混成同一种处理逻辑。

上线前按这个顺序复查：先确认接口是单值还是多值约定，再决定写一次 Decode 还是循环读取；随后覆盖空正文、合法空白、额外值和非法尾部这几类场景；最后给请求体设置合理的大小边界，解析失败时同步记录流元素的错误位置。

相关问题

第二次 Decode 得到 EOF 要记录为告警吗？

如果它是单对象接口的正常尾部检查结果，不需要额外告警；如果第一次 Decode 就返回 EOF，或者第二次返回了语法错误，再按普通输入错误逻辑处理即可。

为什么不直接把请求体全读成字节再调用 Unmarshal？

一次性读取成字节数组便于做大小限制和复用，但会占用和正文等大的内存空间；Decoder 更适合流式处理或者体积较大的输入。选择哪种方式取决于正文大小、协议形态以及你是否需要做多层的尾部校验。

JSON 数组是不是比连续独立对象更适合作为批量接口的格式？

通常更容易做描述和校验，客户端也更容易调试复现。只要同时限制数组长度和整个正文的大小，就能避免无界流式读取造成的内存过度增长问题。

Decoder 面向的是原始输入流，不会自动替你决定上层接口的协议规则。单对象请求第一次解析成功、第二次得到 EOF，属于完全正常的结束状态；第二次得到另一个合法值或者语法错误，才代表正文没有按照约定结束。把这一步写成明确的尾部校验逻辑，能避免只保存第一个对象带来的隐性数据异常问题。