Go io.ReadFull 如何区分短读与真实 EOF：固定长度协议的缓冲区验收

处理固定长度消息时，最容易误判的是“读到了几字节”和“这次读取是否成功”这两件事。Go 的 io.ReadFull 会持续读取，直到填满 len(buf)；如果输入在中途结束，它返回已经读到的 n 和 io.ErrUnexpectedEOF，只有一字节都没读到才是 io.EOF。

验收固定长度数据时，以 err 判断是否完整，以 n 判断已经消费了多少字节；不要把所有 EOF 都当成正常结束。

问题现场：固定长度消息为什么不能只看 err

假设消息头固定为 4 字节，后面再跟一个按协议约定的 8 字节字段。调用方如果只写 if err != nil，很容易把部分填充的 buf 留给后续解析；而固定结构一旦少一字节，字段边界就已经不可信。

buf := make([]byte, 8)
n, err := io.ReadFull(r, buf)
fmt.Println(n, err)

这里的目标不是“尽量读一些”，而是“要么拿到 8 字节，要么明确知道这次块不完整”。这正是 io.ReadFull 和普通 Read 的使用边界。

先看 ReadFull 的返回契约

io.ReadFull(r, buf) 读取的目标长度是 len(buf)。官方文档给出的判断关系很适合直接写进代码审查清单：成功时 n == len(buf) 且 err == nil；没有读到任何字节就遇到结束时返回 io.EOF；已经读到部分字节再结束时返回 io.ErrUnexpectedEOF。

func readBlock(r io.Reader, size int) ([]byte, error) {
	buf := make([]byte, size)
	n, err := io.ReadFull(r, buf)
	if err != nil {
		if errors.Is(err, io.EOF) {
			return nil, io.EOF
		}
		if errors.Is(err, io.ErrUnexpectedEOF) {
			return nil, fmt.Errorf("fixed block short: n=%d want=%d: %w", n, len(buf), err)
		}
		return nil, fmt.Errorf("read fixed block: %w", err)
	}
	return buf, nil
}

把 n 放进错误信息很有用：日志能区分“连接刚好没有数据”和“只收到半个块”。返回错误时不把短缓冲区交给解析器，调用边界也更清楚。

动手验证：三种输入对应三种结果

用 strings.NewReader 构造 8 字节目标，可以快速验证边界：

cases := []string{"", "abc", "abcdefgh"}
for _, input := range cases {
	buf := make([]byte, 8)
	n, err := io.ReadFull(strings.NewReader(input), buf)
	fmt.Printf("input=%q n=%d err=%v\n", input, n, err)
}

• 空输入：n=0，错误是 io.EOF。
• abc：n=3，错误是 io.ErrUnexpectedEOF。
• abcdefgh：n=8，完整成功可记为 err=nil，实际调用仍应检查 err == nil。

固定长度协议的修复写法

协议代码通常先读头部，再根据头部字段确定后续长度。每一次 io.ReadFull 都应当在本层完成校验，不要把“读完以后再统一处理”留给更远的调用方。

func readMessage(r io.Reader) ([]byte, error) {
	header := make([]byte, 4)
	if n, err := io.ReadFull(r, header); err != nil {
		return nil, fmt.Errorf("read header: n=%d: %w", n, err)
	}

	bodySize := int(binary.BigEndian.Uint32(header))
	if bodySize > 1

示例里头部是 4 字节、正文上限是 1 MiB，都是本次协议的明确约束；真实项目应把上限设为业务可接受的值。正文短读时立即返回，避免把不完整数据交给 JSON、压缩包或自定义二进制解析器。

常见问题：短读和 EOF 的复查动作

把 io.EOF 当成唯一失败类型可以吗？

不可以。空输入的 io.EOF 与部分输入的 io.ErrUnexpectedEOF 含义不同，后者说明固定块已被截断。

n 已经等于 len(buf)，还要检查 err 吗？

要检查。契约上完整成功是 n == len(buf) 且 err == nil；调用方不要自行推断错误可以忽略。

普通 Read 能替代 ReadFull 吗？

只有在调用方自己维护循环、短读和错误传播时才可以。固定长度协议优先使用 io.ReadFull，让完整性判断集中在一个清晰的边界。

复查结果：把判断写在读取现场

最终检查可以压缩成一句：目标长度由 len(buf) 或协议字段确定，io.ReadFull 负责填充，n 负责留痕，io.EOF 表示零字节结束，io.ErrUnexpectedEOF 表示固定块中途结束。只要短读不进入下一层解析，后面的错误定位就不会被一块残缺缓冲区带偏。