Go io.ReadFull 读取定长消息怎样处理数据不足

处理定长消息时，io.ReadFull 的关键不是“调用一次 Read”，而是把目标缓冲区填满。只有返回的 n == len(buf) 且 err == nil，调用方才应该把它当作完整消息；如果一开始就没有数据，结果通常是 io.EOF，如果已经读到一部分后输入结束，则是 io.ErrUnexpectedEOF。

官方文档：https://pkg.go.dev/io#ReadFull

定长读取要同时看 n 和 err：n 说明已经拿到多少字节，err 说明为什么没有继续完成。半帧数据不能按正常 EOF 处理。

ReadFull 的成功条件是什么

ReadFull 会持续从 io.Reader 读取，直到填满传入的切片，或者遇到错误。它并不要求底层 Reader 一次返回全部数据，因此网络连接、文件和自定义分块 Reader 都可以使用。

最小写法可以把判断集中在返回值上：

package main

import (
	"fmt"
	"io"
	"strings"
)

func main() {
	// 缓冲区长度就是这条定长消息的边界。
	buf := make([]byte, 4)
	n, err := io.ReadFull(strings.NewReader("PING"), buf)
	if err != nil {
		// 读取未完成时，n 仍可用于判断已经拿到多少字节。
		fmt.Printf("读取 %d 字节失败：%v\n", n, err)
		return
	}
	// n == len(buf) 且 err == nil 才代表完整消息。
	fmt.Printf("完整消息：%q（%d 字节）\n", buf, n)
}

不要只检查 n，也不要把 io.EOF 当成唯一失败类型。对固定长度协议来说，长度完整和错误为空必须同时成立。

为什么数据不足时会出现两种 EOF

如果输入在读取任何字节之前就结束，ReadFull 返回 io.EOF；如果已经读到部分内容才结束，返回 io.ErrUnexpectedEOF。第二种情况说明输入里留下了半条消息，通常需要丢弃当前帧、等待上层重新建立边界，或记录协议异常。

package main

import (
	"errors"
	"fmt"
	"io"
	"strings"
)

func readFrame(r io.Reader, size int) ([]byte, error) {
	// 只在 size 合法时分配固定长度缓冲区。
	if size 

如果需要判断包装后的错误，应使用 errors.Is，不要依赖错误字符串。这样即使函数在错误上增加了上下文，EOF 分类仍然稳定。

把定长读取封装成调用方真正需要的结果

协议层通常不需要把所有底层细节暴露出去，可以把结果收敛成“完整帧”“正常结束”“半帧”“其它读取失败”四类。关键是保留 n 范围内的字节：它们能帮助日志定位长度问题，但不能直接当作可解析消息。

对于复用缓冲区的场景，下一次读取前要重新确认切片长度，不能因为上一次只读到一半就把旧字节尾部误当成新消息。失败分支应只使用 buf[:n]，而不是整个缓冲区。

兼容边界与常见误区

• 空输入：读取目标长度大于零且 Reader 立刻结束时，关注 io.EOF；这和半帧不是同一个协议状态。
• 长度不合法：业务层应先拒绝零或负长度，避免把“没有消息”和“空消息”混成一个含义。
• 其它错误：超时、连接关闭或自定义 Reader 错误不能统一改写成 ErrUnexpectedEOF，否则调用方会失去重试依据。
• 与 ReadAtLeast 的区别：ReadAtLeast 只要求达到最小长度；ReadFull 要求填满整个缓冲区，更适合固定尺寸帧。

记住一个速查式：完整消息看 n == len(buf) && err == nil；起始结束看 n == 0 && errors.Is(err, io.EOF)；半帧看 n > 0 && errors.Is(err, io.ErrUnexpectedEOF)。剩余情况保留原始错误并按业务决定重试或终止。

相关问题

ReadFull 会一次读取完网络数据吗？

不保证一次底层读取完成，但它会持续读取直到缓冲区填满或发生错误，因此调用方不必自行拼接短读结果。

ErrUnexpectedEOF 能当作正常连接关闭吗？

不能。它表示固定长度数据结构在中途遇到 EOF，通常代表当前消息不完整；是否重试要由协议和连接状态决定。