Go gob.Decoder 怎么连续读取多个值并正确判断 EOF

问题通常出现在一个看似合理的判断里：第一次 Decode 成功后，调用方就认为 gob 数据已经读完。实际上，gob.Decoder 面向的是一条值流，同一个 Encoder 可以连续写入多条记录；接收端要继续调用 Decode，直到下一次调用返回 io.EOF。

官方文档：https://pkg.go.dev/encoding/gob#Decoder.Decode

把“成功读到一条值”和“没有下一条值”分开处理：成功就消费当前记录，只有 errors.Is(err, io.EOF) 才是正常结束，其他错误都要保留。

一次 Decode 成功为什么不等于流结束

故障现场往往是这样的：发送方把多条对象写入同一个缓冲区或连接，接收方第一次解码后立即返回，结果后面的记录像是“丢了”。根因不是 gob 只支持一个值，而是把一次调用的结果误当成了整个流的状态。

官方定义里，Decode 读取输入流中的下一个值并写入目标对象；当输入已经位于 EOF 时，它才返回 io.EOF，并且不会修改目标对象。也就是说，EOF 属于“下一条不存在”的边界，不是上一条成功读取的附带结果。

让 Encoder 连续写入多个值

连续读取的前提，是发送端确实把多个值写进同一条编码流。下面示例使用 bytes.Buffer 模拟连接，实际项目也可以替换为文件或网络连接。示例中的注释只解释关键边界，便于迁移到自己的读取循环。

package main

import (
	"bytes"
	"encoding/gob"
	"fmt"
)

type Event struct {
	ID   int
	Name string
}

func main() {
	var stream bytes.Buffer
	enc := gob.NewEncoder(&stream)

	// 同一个 Encoder 依次写入多条值，接收端才能逐条 Decode。
	for _, event := range []Event{
		{ID: 101, Name: "created"},
		{ID: 102, Name: "archived"},
	} {
		if err := enc.Encode(event); err != nil {
			// 编码失败不能被当成“流结束”，应直接返回错误。
			panic(err)
		}
	}

	fmt.Println(stream.Len() > 0) // 预期输出：true
}

关键点是复用同一个 Encoder。如果每条记录都新建独立缓冲区，接收端拿到的就不是一个连续 gob 流，后续读取边界也会变成调用方自己的协议问题。

循环读取时怎样区分 EOF 和真正的错误

接收端的判断顺序应当稳定：先处理成功，再识别 EOF，最后把其他错误返回。用 errors.Is 而不是只比较字符串，可以兼容被包装过的 EOF。

package gobdemo

import (
	"bytes"
	"encoding/gob"
	"errors"
	"fmt"
	"io"
)

type Event struct {
	ID   int
	Name string
}

func readEvents(stream *bytes.Buffer) ([]Event, error) {
	dec := gob.NewDecoder(stream)
	var events []Event

	for {
		var event Event
		err := dec.Decode(&event)
		if err == nil {
			// 每轮使用新的目标值，避免上一条记录残留到本轮。
			events = append(events, event)
			continue
		}
		if errors.Is(err, io.EOF) {
			// 没有下一条值是正常结束，不是失败。
			return events, nil
		}
		// 截断流、类型不兼容等问题不能静默吞掉。
		return nil, fmt.Errorf("decode event: %w", err)
	}
}

上面的函数还需要在 import 中加入 errors、io 和 fmt。这里把 EOF 转换成成功返回，把其他错误包上上下文后继续向上传递；这样调用方可以区分“读完了”和“读坏了”。

故障复盘：复用目标值和截断流要分开看

如果循环里复用一个结构体变量，成功解码时 gob 会把数据写入它；但当下一次调用返回 EOF 时，官方保证目标值不会被修改。不要在收到 EOF 后再读取目标值来推断“最后一条”，应该只使用成功分支中已经追加的数据。

另一类问题是输入只写入了一半，或者中途连接断开。这时返回的通常不是 EOF，而是表示数据不完整的错误。把所有非 EOF 错误都当成正常结束，会让截断记录悄悄消失；把 EOF 当成失败，又会让正常文件读取产生误报。对于不可信来源，还要注意 gob 解码会做有限的输入大小检查，官方文档明确提醒它不适合作为抵御对抗性输入的边界。

常见问题

为什么第一次 Decode 成功后还要继续调用？

因为一次 Decode 只消费下一个值。只有后续调用发现输入已经没有更多值时，才会返回 io.EOF。

EOF 是否应该直接当作异常记录日志？

对完整的文件或已关闭的发送端，EOF 是正常结束。建议用 errors.Is 单独处理；真正需要告警的是截断、类型不匹配或底层读取错误。

小结

连续 gob 读取的判断口诀是：同一个流、逐次 Decode、成功就保存、EOF 才收尾、其他错误不吞掉。这样既能读取多条值，也能把正常边界和数据损坏分开。