Go JSON Decoder 解析连续对象流时怎么区分 EOF 和损坏输入

处理连续 JSON 对象流时，io.EOF 只代表“下一个顶层值不存在了”。一个对象已经完整读完后，下一次 Decode 返回 io.EOF，循环可以正常结束；如果当前字节把 JSON 语法截断或写坏，返回的就是语法错误、io.ErrUnexpectedEOF 或类型错误，不能吞掉。

连续对象流里，io.EOF 只表示“下一个值不存在”

json.NewDecoder 读取的是流，不要求整个输入包成一个数组。多个完整对象可以用空白分隔。判断结束的关键位置在“准备读取下一个对象”这一次调用，而不是看到某个对象字段为空。

dec := json.NewDecoder(reader)
for {
    var msg Message
    err := dec.Decode(&msg)
    if errors.Is(err, io.EOF) {
        // 没有下一个顶层 JSON 值，属于正常收尾。
        break
    }
    if err != nil {
        // 语法损坏、输入截断或目标类型不匹配都不能当成结束。
        return fmt.Errorf("decode message: %w", err)
    }
    handle(msg)
}

因此，空文件或只包含空白的流会直接得到 io.EOF；{"id":1} 后再接一个完整对象也会在下一轮结束。相反，{"id":1 少了右花括号，或者对象之间混入了不合法字符，都应该进入错误分支。标准库文档同时提醒，Decoder 自带缓冲，可能提前从 Reader 读取后续字节，所以不要用底层 Reader 的一次 Read 结果猜测 JSON 是否结束。

先收下 RawMessage，再按 kind 延迟解码

当消息的 payload 可能是订单、告警或心跳时，不要把它声明成 any 后再到处做类型断言。先让外层结构稳定下来，把载荷保存为 json.RawMessage，这样外层读取成功和载荷具体类型就是两件事。

type Envelope struct {
    Kind    string          `json:"kind"`
    Payload json.RawMessage `json:"payload"`
}

type Order struct {
    ID int `json:"id"`
}

type Heartbeat struct {
    At int64 `json:"at"`
}

func decodePayload(raw json.RawMessage, kind string) (any, error) {
    switch kind {
    case "order":
        var v Order
        // 只有确认 kind 后，才解析延迟保存的 payload。
        if err := json.Unmarshal(raw, &v); err != nil {
            return nil, fmt.Errorf("decode order payload: %w", err)
        }
        return v, nil
    case "heartbeat":
        var v Heartbeat
        // 不同 kind 使用各自的目标类型，互不污染流边界。
        if err := json.Unmarshal(raw, &v); err != nil {
            return nil, fmt.Errorf("decode heartbeat payload: %w", err)
        }
        return v, nil
    default:
        return nil, fmt.Errorf("unsupported kind %q", kind)
    }
}

RawMessage 本质上保留了一段原始 JSON，适合把“外层协议能否读取”和“载荷是否符合某种业务结构”分开记录。注意：外层成功不等于载荷业务有效，decodePayload 的错误仍然要上报或隔离。

用错误类型和 InputOffset 判断坏在哪

排查时不要只打印一行“JSON decode failed”。可以把语法错误、截断错误和目标字段类型不匹配分开。json.SyntaxError 通常带有字节偏移；json.UnmarshalTypeError 则说明 JSON 值和 Go 目标字段类型不一致。输入分段到一半就断开时，还要保留 io.ErrUnexpectedEOF 这一类信号。

var env Envelope
err := dec.Decode(&env)
if err != nil {
    var syntaxErr *json.SyntaxError
    var typeErr *json.UnmarshalTypeError
    switch {
    case errors.As(err, &syntaxErr):
        // SyntaxError.Offset 是 JSON 语法位置；记录原始错误便于定位。
        log.Printf("bad syntax at byte %d: %v", syntaxErr.Offset, err)
    case errors.As(err, &typeErr):
        // 类型错误说明值读到了，但目标结构无法接收它。
        log.Printf("field %s has incompatible value: %v", typeErr.Field, err)
    case errors.Is(err, io.ErrUnexpectedEOF):
        // 流在一个 JSON 值中间断开，不能按正常 EOF 处理。
        log.Printf("truncated JSON near byte %d: %v", dec.InputOffset(), err)
    default:
        log.Printf("decode failed near byte %d: %v", dec.InputOffset(), err)
    }
}

InputOffset 是 Decoder 当前输入位置的估计锚点，适合和消息序号、连接 ID 一起写入日志。错误发生后是否继续读，要看协议能否可靠找到下一个顶层值；如果坏数据可能破坏了分隔边界，通常应丢弃当前连接或把剩余字节隔离，不能盲目继续循环。

未知字段要不要拒绝：默认兼容与严格模式的取舍

标准 encoding/json 解码到结构体时，默认会忽略没有对应字段的 JSON 键。这适合允许生产者向后增加元数据的协议；如果未知字段意味着客户端版本不匹配，可以在创建 Decoder 后调用 DisallowUnknownFields()，让外层字段变更尽早失败。

这个开关和 RawMessage 并不冲突：它约束的是解码到结构体时的未知字段，而不是把延迟载荷提前解析。实践中可以对协议 Envelope 采用严格策略，对 payload 采用按 kind 选择的独立结构体；这样既能发现外层拼写错误，也不会为了一个新载荷类型改动所有旧分支。

常见问题

连续 JSON 对象之间必须加逗号吗？

不需要。顶层值可以按空白分隔；逗号是数组或对象内部的语法，不是两个顶层值之间的通用分隔符。

为什么不直接用 json.Unmarshal 解析整个 Reader？

Unmarshal 面向一段完整字节切片；持续输入更适合 Decoder，它能逐个读取顶层值并在下次调用返回 io.EOF。

RawMessage 能避免载荷错误吗？

不能。它只延迟载荷解析；选定具体类型后仍要检查 json.Unmarshal 的返回错误。

遇到非 EOF 错误后还能继续 Decode 吗？

只有在协议能确认错误范围并找到可靠边界时才考虑继续。对可能破坏分隔结构的截断或乱码，终止当前流通常更安全。