Go json.Decoder 怎样处理多个连续 JSON 值

Go 里要连续读取多个顶层 JSON 值，直接用同一个 json.Decoder 反复调用 Decode 即可。每次调用取出下一个完整值；读完后返回 io.EOF，它表示输入正常结束，不是业务错误。只有在中途拿到语法错误或类型错误时，才应该终止并记录问题。

先分清连续值和数组

下面两种输入都可能出现在日志流、消息管道或批量接口里，但读取协议不同：

两者都可以流式处理，但不要用 dec.More() 判断顶层连续值。More 的语义是当前数组或对象容器里是否还有元素；顶层输入没有这个容器上下文。

用 Decode 循环读取多个 JSON 值

对于换行或空白分隔的对象，循环体只负责处理一个对象，循环条件负责区分正常结束和异常。不要把所有输入先读成 []byte 再切字符串，这样既容易破坏 JSON 字符串内部的空白，也失去了流式读取的意义。

package main

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

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

func main() {
	// 空白分隔两个顶层 JSON 对象，不需要额外的逗号或数组括号。
	input := strings.NewReader(`{"id":1,"kind":"created"}
{"id":2,"kind":"updated"}`)
	dec := json.NewDecoder(input)

	for {
		var event Event
		// 每次 Decode 只接收一个完整 JSON 值，并写入当前对象。
		err := dec.Decode(&event)
		if err == io.EOF {
			// 没有下一个值时，结束是正常结果。
			break
		}
		if err != nil {
			// 第二个值损坏时不能当作正常结束，应保留错误上下文。
			panic(fmt.Errorf("decode event: %w", err))
		}
		fmt.Printf("%d %s\n", event.ID, event.Kind)
	}
}

这里的关键是每轮重新声明 event，避免上一个对象的字段值在异常输入时残留。生产代码通常会把 panic 换成带输入来源、记录编号或请求 ID 的错误返回。

数组输入要用 Token 和 More

如果协议明确规定输入必须是一个 JSON 数组，就先读取数组开始分隔符，再用 More 读取元素。这样可以在读完元素后检查闭合分隔符，发现数组没有正常结束。

func readArray(dec *json.Decoder) error {
	// 读取并确认数组开始分隔符，避免把对象误当成数组。
	token, err := dec.Token()
	if err != nil {
		return err
	}
	if token != json.Delim('[') {
		return fmt.Errorf("expected array, got %v", token)
	}

	for dec.More() {
		var event Event
		// More 只表示当前数组仍有元素，Decode 负责取出该元素。
		if err := dec.Decode(&event); err != nil {
			return err
		}
		fmt.Println(event.ID, event.Kind)
	}

	// 读取闭合分隔符，确认数组边界完整。
	end, err := dec.Token()
	if err != nil {
		return err
	}
	if end != json.Delim(']') {
		return fmt.Errorf("expected array end, got %v", end)
	}
	return nil
}

生产环境要处理的三个边界

中途坏数据。如果第一条能解码、第二条出现非法 JSON，第二次 Decode 会返回语法错误。此时不能把它改判为 io.EOF，否则调用方会误以为整条流已经完整消费。

尾部不是空白。连续 JSON 值后面如果还有不属于 JSON 的字节，下一次 Decode 通常会报语法错误。若协议允许 JSON 后拼接其他格式，应先在协议层切分，而不是依赖 Decoder 猜测边界。

解码器会预读。NewDecoder 自带缓冲，可能从底层 Reader 读取超出当前值的数据。如果解码完一个值后还要接管剩余字节，可在下一次 Decode 前读取 dec.Buffered()；这个 Reader 只在下一次 Decode 或 Token 前有效，且它反映的是已读入 Decoder 但尚未消费的数据。

对象字段还可以按协议选择 dec.DisallowUnknownFields()，让结构体中不存在的字段尽早暴露。它只影响目标是结构体的解码，不会替代输入长度限制、请求超时或上游消息大小控制。

发布前检查清单

• 输入协议是否明确是连续顶层值，还是一个数组。
• 循环是否只把 io.EOF 当作正常结束。
• 每个对象是否使用独立目标变量，并保留错误上下文。
• 数组是否检查了 [ 与 ] 的边界。
• 是否考虑 Decoder 预读，以及是否需要在下一次 Decode 前接管 Buffered 数据。

相关问题

多个 JSON 对象之间必须换行吗？不必须，JSON 空白都可以作为分隔；换行只是日志和流文件里更容易观察的写法。

能不能用 json.Unmarshal 处理这类输入？如果输入是一个完整数组，可以；如果是多个顶层值，Decoder 更适合逐个读取并控制结束边界。

为什么读完一个值后底层 Reader 的位置看起来超前？因为 Decoder 可能预读。需要混用底层 Reader 时，先按官方语义处理 Buffered 返回的剩余数据，再继续读取底层流。