Go io.ReadFull 配合网络流时为什么不能假设一次 Read 读满

Go 里最容易误判网络读取的一点，是把一次 Read 想成“一次收齐一个消息”。实际上，net.Conn 提供的是字节流，满足 io.Reader 契约；一次读取只保证返回当前拿到的部分数据，不保证填满缓冲区，也不保证对应一次发送。需要固定长度时，应该让 io.ReadFull 负责补齐，并用 n 和 err 一起判断结果。

为什么网络流的一次 Read 只返回一部分数据

io.Reader.Read 的签名是 Read(p []byte) (n int, err error)。它的语义是“最多读入 len(p) 个字节”，不是“必须读满”。当内核缓冲区当前只有一部分数据，或者底层连接在本次调用中暂时只能交付一部分数据时，返回短读是合法结果。

TCP 也没有应用层消息边界。发送端连续写入的包头和正文，接收端可能一次读到，也可能拆成几次读到。因此判断是否收到完整字段时，要看协议长度，而不是看一次 Read 的返回长度。

io.ReadFull 怎样把固定长度消息读完整

如果协议规定包头固定为 8 字节，可以把“读够 8 字节”交给 io.ReadFull。它会反复调用 Reader，直到填满目标缓冲区，或者遇到错误。只有 err == nil 时，才可以把缓冲区当成完整包头解析。

// 读取固定长度包头；一次 Read 不够时由 io.ReadFull 继续补齐。
header := make([]byte, 8)
n, err := io.ReadFull(conn, header)
if err != nil {
    // n 可能大于 0，说明连接中断前只收到半个包头。
    return fmt.Errorf("read header: got %d/%d bytes: %w", n, len(header), err)
}

// err 为 nil 时 n 必然等于 len(header)，此时才解析字段。
payloadLen := binary.BigEndian.Uint32(header[4:8])

固定长度场景下，io.ReadFull 把“多次短读”隐藏在读取协调层，但不会替你解决长度是否合法、正文是否超限等协议问题。收到包头后仍要检查 payloadLen，再决定是否分配正文缓冲区。

消息长度不确定时不要误用 io.ReadFull

io.ReadFull 适合“长度已知”的字段。如果正文长度由包头给出，应先固定读取包头，再读取长度前缀指定的正文；如果消息以换行或其他分隔符结束，可以使用带缓冲的读取器按分隔符处理。把一个没有固定长度的流强行塞进大缓冲区，会让程序一直等到填满、连接关闭或超时。

生产代码里的超时、EOF 和短读检查

网络读取还可能遇到读超时、对端关闭和连接中断。若 n > 0，先保留这部分数据并记录当前阶段；若固定字段最终只收到一部分，通常应将其视为不完整输入，而不是拿半个字段继续解析。对可重试的连接超时，要结合协议是否允许续读，不能仅凭错误字符串决定重试。

一个实用检查顺序是：先确认目标长度，再记录 n；接着区分 io.EOF 与 io.ErrUnexpectedEOF；最后根据连接是否可重建、消息是否幂等来决定重试。这样既不会把正常短读当成异常，也不会把半包误当成完整消息。

相关问题

Read 返回 n 小于缓冲区长度时一定是网络故障吗？

不一定。短读符合 io.Reader 契约，只有在协议要求固定长度时才需要继续读取或交给 io.ReadFull。

为什么 ReadFull 返回 ErrUnexpectedEOF？

这表示已经读到部分字节，但输入在填满目标缓冲区前结束；应按不完整字段处理，并记录实际的 n。

可以用 len(buf) 判断消息是否收齐吗？

不可以。len(buf) 是目标容量；是否收齐必须由协议长度、分隔符或 io.ReadFull 的错误结果共同确认。