Go io.ReadFull 读取定长消息时怎么区分短读和提前结束

处理固定长度的二进制消息时，io.ReadFull 的判断重点不是“底层这次 Read 返回了多少”，而是最终的 n 和 err。当缓冲区长度为 8 时，只有 n == 8 && err == nil 才能把它交给协议解析器；一次字节也没有读到就结束是 io.EOF，读到一部分后输入提前结束则是 io.ErrUnexpectedEOF。

先把定长消息的成功条件写死

io.ReadFull(r, buf) 等价于要求从 r 读取正好 len(buf) 个字节。底层 Reader 可能一次只返回几个字节，因此不能把一次 Read 的短返回当成协议层短包。ReadFull 会在内部继续读，直到缓冲区填满或错误终止。

package main

import (
	"bytes"
	"errors"
	"fmt"
	"io"
)

func main() {
	// 协议规定消息体必须有 8 字节，这里故意只提供 3 字节。
	buf := make([]byte, 8)
	n, err := io.ReadFull(bytes.NewReader([]byte{0x01, 0x02, 0x03}), buf)
	// 先看长度，再看错误；部分数据不能交给完整帧解析器。
	fmt.Printf("n=%d, unexpected=%t, eof=%t\n", n,
		errors.Is(err, io.ErrUnexpectedEOF), errors.Is(err, io.EOF))
}

这个例子得到的核心结论是 n=3 且错误为 io.ErrUnexpectedEOF。bytes.Reader 只是演示输入，真实场景可以是 TCP 连接、文件或带缓冲的 Reader。

用 n 和 err 区分 EOF、短消息与底层故障

官方契约可以压缩成三种常见结果：n == 0 && errors.Is(err, io.EOF) 表示没有新消息且输入结束；0 且为 io.ErrUnexpectedEOF 表示消息只到了一部分；n == len(buf) && err == nil 才是完整消息。其他网络或设备错误则应保留原错误，交给上层决定重试和告警策略。

判断时推荐使用 errors.Is，这样可以兼容被包装过的错误。特别要注意：不要把所有 EOF 都当成异常，也不要因为 n > 0 就继续解码。对长度字段已经损坏的协议帧，半帧数据通常没有独立业务意义。

在读取循环中决定丢弃、重试还是结束

如果协议循环每次都复用一个缓冲区，读取失败后不要继续使用旧内容。可以把本次 n 写入日志，再根据错误类型选择动作：

func readFrame(r io.Reader, size int) ([]byte, error) {
	// size 来自已确认的协议约束，避免按不可信长度无限分配内存。
	buf := make([]byte, size)
	n, err := io.ReadFull(r, buf)
	if err != nil {
		// 部分帧只用于诊断，不返回给完整帧解析器。
		if errors.Is(err, io.ErrUnexpectedEOF) {
			return nil, fmt.Errorf("消息被截断：已读 %d/%d 字节：%w", n, size, err)
		}
		// 零字节 EOF 和其他 Reader 故障都保留原始语义。
		return nil, err
	}
	return buf, nil
}

若底层 Reader 返回错误时已经填满缓冲区，ReadFull 的契约会把这次错误视为成功完成，调用方仍应以 n == len(buf) && err == nil 为准。对于超时、连接重置等非 EOF 错误，是否重试取决于协议是否允许重新建立消息边界，不能在通用读取函数里擅自重放业务操作。

常见问题

io.ReadFull 会把一次短读直接返回吗？

不会。只要没有错误，它会继续读取，直到填满缓冲区；这里讨论的“短读”是最终输入不足，而不是某一次底层 Read 的返回长度较小。

为什么部分 EOF 不是 io.EOF？

因为调用者要求的是一个完整定长块。部分数据后结束代表块被截断，使用 io.ErrUnexpectedEOF 能让上层区别“自然读完”和“消息不完整”。

什么时候应该改用 io.ReadAtLeast？

当只要求至少读取某个最小长度、允许缓冲区还剩空间时可考虑 io.ReadAtLeast；严格固定长度的协议帧仍优先使用 io.ReadFull。

记住一条检查式即可：n == len(buf) && err == nil 才能解析完整消息；其余情况先处理边界，再决定连接、重试和日志策略。