Go json.Decoder 怎样逐个解析对象流

当输入不是一个完整 JSON 数组，而是连续到达的多个 JSON 对象时，json.Unmarshal 就不太合适了。更稳妥的做法是创建一个 json.Decoder，在循环里反复调用 Decode：读到对象就处理，返回 io.EOF 就把它当成对象流正常结束，其他错误则保留对象序号后停止。

这个模式适合文件、消息管道和 HTTP 请求体等 io.Reader 输入。关键不是“循环调用 Decode”本身，而是明确每个返回值代表的边界。

先确定对象流的边界

对象流可以写成两个或多个 JSON 对象首尾相接，中间允许有空白，例如 {"id":1}{"id":2}。它与 [{"id":1},{"id":2}] 不同：前者的顶层值是多个对象，后者的顶层值只有一个数组。

json.Decoder 接收一个 io.Reader，内部负责从输入中找到下一个完整 JSON 值。每次成功的 Decode 只消费一个值，下一次调用会继续读取后面的值。因此不要在循环外先把整个 Reader 读入内存，也不要把“读到一个对象”误判为“输入已经结束”。

用 Decode 循环逐个取对象

最小的可复用写法是让结构体在每轮接收一个对象。成功后立即处理当前对象，下一轮继续读取；这样不需要提前知道对象数量。

package main

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

type Event struct {
    ID   int    `json:"id"`
    Kind string `json:"kind"`
}

func readEvents(r io.Reader) error {
    dec := json.NewDecoder(r)
    var event Event

    for index := 1; ; index++ {
        // 每轮只消费一个 JSON 对象，成功后立刻交给业务处理。
        err := dec.Decode(&event)
        if errors.Is(err, io.EOF) {
            // 没有下一个对象时，EOF 是对象流的正常结束信号。
            return nil
        }
        if err != nil {
            // 非 EOF 表示输入或目标类型有问题，保留对象序号便于排查。
            return fmt.Errorf("第 %d 个对象解析失败: %w", index, err)
        }

        // 这里替换成入队、落库或调用业务函数。
        fmt.Printf("event=%d kind=%s\n", event.ID, event.Kind)
    }
}

func main() {
    // 连续对象之间只有空白分隔，不需要额外包一层数组。
    input := `{"id":1,"kind":"created"} {"id":2,"kind":"updated"}`
    if err := readEvents(strings.NewReader(input)); err != nil {
        fmt.Println(err)
    }
}

这里使用 errors.Is 判断 io.EOF，比直接比较错误值更适合可能被包装过的读取错误。结构体可以复用，但每次成功解码后应当在业务处理结束前使用当前值；如果对象字段存在缺省值，需在下一轮前按业务需要重置。

区分正常结束和坏输入

循环中最容易写错的是把所有错误都当成“读完了”。正确的分支只有三类：

• 没有错误：拿到一个对象，处理它，然后继续。
• io.EOF：Reader 没有下一个 JSON 值，对象流正常收尾。
• 其他错误：可能是 JSON 语法损坏、目标字段类型不匹配，或者底层 Reader 失败，应停止并返回。

空输入也会在第一次 Decode 时返回 io.EOF。如果业务规定“至少要有一个对象”，可以额外记录计数后把空流转成业务错误；这不是 Decoder 的错误，而是入口协议的要求。

把读取模式放进实际入口

文件和 HTTP 请求体都满足 io.Reader，因此核心函数不需要知道输入来自哪里。文件场景要负责关闭文件；HTTP 场景要负责关闭响应体，并在边界明确时限制读取量。

import "os"

// 文件输入：把文件生命周期留在入口函数，解析函数只关注 Reader。
func decodeFile(path string) error {
    file, err := os.Open(path)
    if err != nil {
        return fmt.Errorf("打开文件失败: %w", err)
    }
    defer file.Close() // 无论解析成功还是失败，都释放文件描述符。
    return readEvents(file)
}

// HTTP 输入：请求体不是数组时，也可以直接交给同一个对象流函数。
func decodeHTTPBody(body io.ReadCloser) error {
    defer body.Close() // 解析完成后关闭响应体，避免连接和资源长期占用。
    return readEvents(body)
}

上面的示例省略了 os 导入和 HTTP 路由细节，重点是入口只负责资源生命周期。若输入来自不可信请求，还应在传给 Decoder 前使用 io.LimitReader 或框架的请求体上限；对象流的“逐个读取”不等于无限制读取。

用判断清单选择方案

可以把这个模式记成一句话：成功值继续，EOF 收尾，其他错误返回。只要对象之间是连续的 JSON 值，而不是一个需要整体校验的数组，json.Decoder 就能让边界落在每次 Decode 调用上。

相关问题

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

不必须。JSON 空白可以是空格、换行或制表符，Decoder 关注的是下一个完整值；为了日志可读性，生产协议仍建议每个对象独占一行。

为什么不能把 EOF 当成解析失败？

因为流式输入天然有结束位置。EOF 说明 Reader 没有更多内容，不代表前一个对象失败；只有其他错误才表示当前读取过程没有按预期完成。

解析错误后还能继续读下一个对象吗？

通常不应盲目继续。语法错误可能让边界不再可靠；除非协议有明确的帧边界和跳过规则，否则返回错误并让上层决定重试或丢弃更安全。