Go JSON Decoder 为什么允许多个 JSON 值连续出现

把两个 JSON 对象写在同一个输入里，json.Decoder 可能连续返回两次成功，这不是它“漏校验”，而是它的职责本来就是从 io.Reader 中读取下一个顶层 JSON 值。官方示例也把多个对象作为 JSON 流逐个 Decode。

需要处理日志流、消息流或逐条请求时，连续顶层值是 Decoder 的正常用法；需要一个严格 JSON 文档时，必须在第一次 Decode 后再检查尾部，而不能只看第一次是否成功。

先区分 JSON 文档和 JSON 值流

日常说“一个 JSON”时，通常指一份完整文档，例如 {"id":1} 或 [1,2,3]。但 Decoder 面对的是流：它不要求输入在第一个值结束后立刻到达 EOF，而是保留读取下一个值的能力。下面这段输入包含两个独立的顶层对象，它们不是一个对象，也不是一个数组：

{"id":1}
{"id":2}

第一次 Decode 消费第一个对象，第二次消费第二个对象，第三次才在输入耗尽时返回 io.EOF。换句话说，Decode 的“成功”只证明当前值完整且能转换到目标类型，并不自动证明后面没有字节。

用 Decode 循环读取多个顶层值

流式协议可以把每条消息编码成一个 JSON 值，常见形式是“一个对象一条记录”，对象之间用换行或其他 JSON 空白隔开。读取时不要把 io.EOF 当成业务失败，也不要把所有错误都当成结束：

package main

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

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

func readEvents(input string) error {
	dec := json.NewDecoder(strings.NewReader(input))
	for index := 1; ; index++ {
		var event Event
		// 每次只取一个顶层值；EOF 代表流已正常读完。
		err := dec.Decode(&event)
		if err == io.EOF {
			return nil
		}
		if err != nil {
			return fmt.Errorf("第 %d 条 JSON 无效: %w", index, err)
		}
		// 这里处理已经成功解码的单条事件。
		fmt.Printf("%d %s\n", event.ID, event.Kind)
	}
}

这个循环的边界很清楚：正常结束只有 io.EOF，中间出现半截对象、非法逗号或类型转换问题，都应该把错误返回给上层。生产代码若从网络连接读取，还要根据协议决定连接关闭、超时和重试策略，不能因为 Decoder 支持多值就无限等待下一条消息。

只允许一个 JSON 值时检查尾部

HTTP 请求体、配置文件和某些签名输入通常要求“恰好一个 JSON 值”。最容易犯的错是只调用一次 Decode：输入 {"id":1}{"id":2} 时第一次调用成功，第二个对象却被悄悄留在流中。

func decodeOne(input string) (Event, error) {
	dec := json.NewDecoder(strings.NewReader(input))
	var event Event
	// 第一次 Decode 负责读取唯一主体。
	if err := dec.Decode(&event); err != nil {
		return Event{}, fmt.Errorf("主体 JSON 无效: %w", err)
	}

	var extra any
	// 第二次 Decode 专门确认尾部只有允许的空白。
	if err := dec.Decode(&extra); err != io.EOF {
		if err == nil {
			return Event{}, fmt.Errorf("输入包含多个顶层 JSON 值")
		}
		return Event{}, fmt.Errorf("JSON 尾部无效: %w", err)
	}
	return event, nil
}

第二次调用有三种结果：返回 io.EOF，说明主体后只有空白；返回 nil，说明又读到了一个合法 JSON 值；返回其他错误，说明尾部存在不能接受的内容。这样既能拒绝多值输入，也能拒绝主体后的乱码。

如果目标是数组内的多个元素，应传入一个数组并让 Decoder 解析数组结构；如果目标是逐条消息，则可以采用顶层值流。两者的协议含义不同，不要只因为都能调用 Decode 就混为一谈。

按协议选择 Decoder 或 Unmarshal

Unmarshal 适合已经拿到完整字节片段、并把它当作一个 JSON 文档解析的场景；Decoder 更适合边读边处理，且官方文档提醒它会自行缓冲，可能从底层 Reader 多读一些数据。如果一个服务既支持流式上传又支持单文档请求，最好在协议层明确区分入口，并为单文档入口保留尾部校验。

相关问题

两个 JSON 值之间必须换行吗？

不必须。换行、空格、制表符等 JSON 空白都可用于分隔；换行只是日志流里最容易观察的形式。

第二次 Decode 返回 nil 一定是解析错误吗？

对严格单值接口来说是协议错误，因为它说明输入中还有第二个合法顶层值；对流式接口来说则是下一条消息。

为什么不直接检查 Reader 是否读完？

Decoder 可能提前缓冲底层 Reader，Reader 的 EOF 与 JSON 值边界不是同一个概念。使用 Decoder 的第二次 Decode 更能表达“尾部是否还有 JSON 值”。

遇到 io.EOF 时要记录成错误日志吗？

在完整流正常结束的循环中不用；若业务协议要求必须还有下一条消息，则应由业务层判断，而不是把所有 EOF 都当作 JSON 语法错误。

参考：encoding/json 官方文档、Go 标准库 Decoder 源码、Go 官方 Decoder 示例。