Go encoding/json 怎样用 Decoder 流式读取多个对象处理空输入并保留错误边界

我在接收按行或按消息拼接的 JSON 时，最容易踩的坑不是 json.Unmarshal 本身，而是把“多个顶层对象”误当成一个 JSON 数组。输入如果是 {"id":1}\n{"id":2}，更合适的做法是用 json.NewDecoder 循环调用 Decode：每次成功得到一条记录，下一次返回 io.EOF 才算正常结束；空输入同样返回 io.EOF，不能悄悄生成一条零值记录。

多个 JSON 对象应该怎样建模

json.Decoder 从 io.Reader 读取输入，并且允许连续解码多个 JSON 值。它内部会预读一部分数据，所以不要假设底层 Reader 每次只提供一个对象；真正的记录边界由 Decode 识别。下面的例子故意使用两个相邻对象，换行只是可读空白，并不是协议必须条件。

package main

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

type Event struct {
    ID   int    `json:"id"`
    Name string `json:"name"`
}

func readEvents(input io.Reader) ([]Event, error) {
    dec := json.NewDecoder(input)
    var events []Event
    for {
        var event Event
        // 每次 Decode 只接收一个顶层 JSON 值，成功后再读取下一条。
        err := dec.Decode(&event)
        if err == io.EOF {
            // 没有下一条值是正常结束，空输入也会走到这里。
            return events, nil
        }
        if err != nil {
            // 保留原始错误，避免把截断或语法错误伪装成正常结束。
            return events, fmt.Errorf("decode JSON at offset %d: %w", dec.InputOffset(), err)
        }
        events = append(events, event)
    }
}

func main() {
    // 连续顶层对象不需要额外包成数组。
    input := strings.NewReader(`{"id":1,"name":"open"}
{"id":2,"name":"close"}`)
    events, err := readEvents(input)
    if err != nil {
        panic(err)
    }
    fmt.Println(len(events))
}

这里的返回值保留了已经成功读取的记录。调用方可以根据业务决定“部分成功后停止”还是把整个批次标记为失败，但不应把非 EOF 错误吞掉。若协议要求一条都不能少，可以在外层事务或临时文件中提交，而不是修改 Decode 循环的错误语义。

空输入、结尾空白和损坏数据要分开

循环里只把 io.EOF 当作结束信号。输入为空或只有空白时，第一次 Decode 就返回 EOF，结果是空切片；输入在第二个对象中途断掉时，通常会返回 io.ErrUnexpectedEOF 或具体的语法错误，这代表数据不完整，应该交给重试、隔离或告警逻辑。

InputOffset 返回的是最近一次已返回 token 的结束位置，也是下一个 token 的起点附近；由于 Decoder 会缓冲，底层 Reader 实际读取的字节可能更多。因此它适合写入诊断日志，不应被当成“错误字符的精确下标”。

不要用 More 判断连续顶层对象

Decoder.More 的语义是判断当前数组或对象中是否还有元素。连续的顶层对象没有一个外层数组上下文，直接用 More 会让代码的结束判断失去依据。只有在输入明确是 [{"id":1},{"id":2}] 时，才适合先读取左方括号，再在数组内部使用 More。

同样，不要因为看到第一条记录成功就假设后面的字节一定合法。Decoder 可能已经预读尾部内容，但它只会在后续 Decode 时继续验证；所以每一次返回都要检查错误，特别是消息边界来自网络或文件追加时。

把流式解码放进排障清单

遇到“少读一条”时，先记录输入是否为空、已成功记录数、最近一次 InputOffset 和原始错误类型；再确认上游发送的是连续 JSON 值、数组，还是 NDJSON。需要严格字段时可调用 DisallowUnknownFields，但这会把上游新增字段变成错误，适合契约明确的内部接口，不适合随时扩展的公共事件流。

对我来说，最稳的边界是把 EOF、语法/截断、类型不匹配分成三个分支：EOF 结束，语法或截断进入补偿，类型错误进入数据质量处理。这样即使流中已经成功解出几条记录，后续决策仍然有依据。

常见问题

连续 JSON 对象之间必须换行吗？

不必须。Decoder 识别 JSON 值边界，空白只影响可读性；实际协议仍应规定分隔和消息结束方式。

空输入应返回 nil 切片还是错误？

标准库层面是 EOF。示例把它转换为空结果；如果业务要求至少一条记录，应在调用层单独检查数量。

Decode 出错后还能继续读吗？

不要把继续读取当成通用恢复策略。语法已损坏时后续边界未必可信，除非协议有明确的消息隔离和重新同步点。