当前位置：首页 > 文章列表 > Golang > Go教程 > Go encoding/json 怎样用 Decoder 流式读取多个对象处理空输入并保留错误边界

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

来源：17golang原创 2026-11-07 03:40:35 0浏览收藏

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

要点速览

连续顶层 JSON 值用 Decoder 循环读取，不要用 dec.More() 判断流的结束。
io.EOF 是干净结束；io.ErrUnexpectedEOF、json.SyntaxError 和类型错误都应保留。
用 InputOffset 记录最近一次已确认的字节边界，便于日志定位和重试策略判断。

多个 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 循环的错误语义。

Go encoding/json Decoder 从 io.Reader 读取连续 JSON 对象并将 Decode 结果交给记录切片的静态关系说明图 — 图1：结构说明图，展示 io.Reader、json.Decoder、Decode 和 Event 之间的静态关系；这不是运行截图。

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

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

输入情况	典型结果	处理建议
空字节或只有空白	第一次 Decode 返回 io.EOF	按空批次处理，是否允许由业务决定
一个或多个完整对象后到流尾	后续 Decode 返回 io.EOF	提交已读记录，正常结束
对象只写了一半	io.ErrUnexpectedEOF 或语法错误	保留错误，等待补齐或隔离原始输入
字段类型不匹配	json.UnmarshalTypeError	检查契约，不要用重试掩盖数据问题

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

Go JSON 流的空输入、完整对象、截断对象与类型错误边界静态关系说明图 — 图2：边界说明图，把空输入、完整对象、截断 JSON、SyntaxError 和 UnmarshalTypeError 分组展示；这不是运行结果截图。

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

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

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

把流式解码放进排障清单

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

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