Go json.Decoder 为什么连续读取时遇到 EOF

json.Decoder.Decode每次读取下一个完整JSON值。当输入已结束、只剩空白且没有下一个值时，连续读取循环会收到 io.EOF，通常应正常退出。对象或字符串尚未结束时发生的截断则是错误，不能把所有包含“EOF”的错误文本都当作成功。

官方地址：https://go.dev/

假设导入程序已经读到两条记录，第三次Decode返回EOF。这不一定是第三条记录损坏，也可能是文件本来就只有两条。先定义输入协议，才能决定EOF代表正常结束还是缺少必需数据。

先确定输入是值流还是数组

连续对象之间可以用换行或其他合法空白分隔，换行并不是Decoder的记录边界。带格式缩进的对象跨多行也能是一个值。若协议严格要求一行一条，应额外设计逐行输入规则，而不是假设Decode每调用一次只读一行。

数组本身也是一个JSON值。把整个数组Decode进Entry结构体不会自动变成逐元素读取；需要切片目标，或先消费左方括号，再在当前数组范围用More判断元素，最后消费右方括号。

让同一个Decoder持有读取位置

把解码器建在循环外。它有自己的预读缓冲，可能从底层Reader多读取尚未Decode的数据。每轮重新NewDecoder会丢掉上一实例已缓冲的后续字节，导致底层Reader提前EOF。

同理，不要在Decoder使用期间又直接对同一个Reader调用ReadAll或换一个扫描器读取，除非明确处理了已预读内容。需要把解析后的剩余字节交给其他协议时，应考虑Decoder.Buffered与底层Reader的组合，而不是仅查看底层Reader剩余长度。

把正常EOF与解码错误分开

以下完整示例只处理独立对象值流。保存为main.go即可阅读或自行执行：

package main

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

type Entry struct {
    Key string `json:"key"`
    Count int `json:"count"`
}

func consume(r io.Reader) (int, error) {
    dec := json.NewDecoder(r) // 整个值流共用一个解码器，保留内部缓冲。
    total := 0
    for {
        var item Entry // 每轮新建目标，避免缺失字段沿用上条数据。
        err := dec.Decode(&item)
        if err == io.EOF {
            return total, nil // 没有下一个值，是协议允许的正常结束。
        }
        if err != nil {
            return total, fmt.Errorf("第%d条解码失败: %w", total+1, err)
        }
        // 只有Decode成功才处理；失败时不使用可能已部分修改的目标。
        if item.Key == "" || item.Count 

key=alpha count=4
key=beta count=7
处理完成，共2条

上面是代码的预期输出，没有声称已在本机执行。循环先判断直接返回的io.EOF，再处理其他错误，最后才使用item。空输入在这个“允许零条”的协议中返回零条成功；如果业务要求至少一条，应在consume返回后检查数量。

若把第二个对象截断到字段名或冒号附近，预期得到解码错误而不是两条成功。对于io.ErrUnexpectedEOF、语法错误和字段类型不匹配，应保留错误并停止当前导入；不能用strings.Contains(err.Error(), "EOF")模糊匹配。

每轮新建Entry也有意义：JSON对象没有出现的字段不会自动代表上一条记录。重复使用带旧内容的结构体或map，容易把前一条数据误带入后续处理。

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

HTTP配置接口或单文件配置往往只允许一个JSON值。第一次Decode成功不代表尾部没有第二个对象，下面函数可放到同一文件并复用Entry及导入：

func decodeOne(r io.Reader) (Entry, error) {
    dec := json.NewDecoder(r)
    var item Entry
    if err := dec.Decode(&item); err != nil {
        return Entry{}, fmt.Errorf("读取首个JSON值: %w", err)
    }
    var extra json.RawMessage
    // 第二次Decode必须是EOF，才能排除额外值或非法尾部内容。
    err := dec.Decode(&extra)
    if err == io.EOF {
        return item, nil
    }
    if err != nil {
        return Entry{}, fmt.Errorf("JSON尾部内容错误: %w", err)
    }
    return Entry{}, fmt.Errorf("只允许一个JSON值")
}

这里用RawMessage接收可能存在的任意额外值。如果第二次成功，即使内容是null，也属于多出的JSON值；如果第二次报语法错误，则尾部不是合法结束。不能把“第二次不是一个对象”误当成“尾部没数据”。

decodeOne只负责结构上的单值约束，字段必填、范围和未知字段策略仍需按业务补充。网络输入还应有大小和时间限制，否则等待尾部结束也可能持续阻塞。

按输入来源安排结束与清理

文件Reader读到末尾才产生EOF；持续连接若没有下一条数据也没有结束信号，Decode可能等待，而不是立即返回EOF。是否结束由底层输入和协议共同决定。不要用忙循环反复重试同一个已经耗尽的Reader。

Decoder接收io.Reader，不接管文件或HTTP响应体的关闭责任。打开文件或成功获得响应后，应由拥有者在合适的函数作用域关闭。若读取已经消费完HTTP Body，再创建Decoder读取同一个Body，首个Decode就可能是EOF；这与原始响应是否为空是两回事。

More可以用来判断顶层值流有没有结束吗？

不要这样替代Decode的错误判断。More描述当前数组或对象是否还有元素，不是通用的输入结束检测接口。

末尾多一个换行为什么仍是EOF？

空白不会产生新的JSON值，前一个值处理完后再次读取，无新值可得就是正常流结束。

EOF后能继续向同一个Decoder追加新文件吗？

不应把耗尽输入当作可自动续接的消息队列。新输入应有明确Reader和协议边界，通常为新来源创建解码器。

连续读取的关键是先固定输入形状，再复用解码器状态，只有成功才处理结果。io.EOF用于正常结束时，不必当作异常；截断与非法内容仍应保留为失败。

官方资料：Decoder说明；io.EOF定义。