io.readfull总是返回io.errunexpectedeof，因为它严格要求填满整个缓冲区，只要数据源在预期长度前结束（如文件截断、连接中断），就报此错而非io.eof，专为定长协议设计。
io.ReadFull 为什么总是返回 io.ErrUnexpectedEOF
因为 io.ReadFull 要求必须读满指定字节数，只要底层 Reader 在预期长度前就返回 EOF（比如网络连接断开、文件提前结束），它就直接返回 io.ErrUnexpectedEOF，而不是像 io.Read 那样接受“读到多少算多少”。这不是 bug，是设计使然——它专为“严格定长协议”而生，比如解析二进制头、固定长度字段。
常见误用场景：
- 对一个可能短于预期的文件调用
io.ReadFull，没做错误判断就 panic - 把
os.Stdin当作可靠输入源直接传入，但用户只输几个字符就按了 Ctrl+D - 用在 HTTP body 上却没先检查
Content-Length是否匹配
正确使用 io.ReadFull 的三个前提
它不是万能读取器，必须满足以下条件之一才能安全使用：
- 你**完全确定**数据源至少有 N 字节可用（例如：已知文件大小 ≥ N，或协议明确约定该字段恒为 N 字节）
- 你**主动控制写入端**，且双方约定好长度（如自定义 TCP 协议中先发 4 字节长度，再发对应字节数的 payload）
- 你愿意把
io.ErrUnexpectedEOF当作有效业务信号来处理（比如表示客户端异常断连）
否则，应改用 io.Read + 循环，或用 io.ReadAtLeast（允许多读但不允少读）。
io.ReadFull 和 io.Read 循环的区别在哪
关键差异在语义和错误处理逻辑：
-
io.ReadFull(buf)：要么成功填满buf，要么失败（io.EOF表示刚好读完且不足，io.ErrUnexpectedEOF表示中途断；其他错误原样透出） -
io.Read循环：每次读尽可能多，需手动累加计数、检查是否达到目标长度，容易漏掉最后一次短读或误判 EOF
示例对比（读取 8 字节）：
// 推荐：语义清晰，错误即意图
err := io.ReadFull(r, buf[:8])
if err != nil {
if err == io.ErrUnexpectedEOF || err == io.EOF {
// 明确知道：数据不足 8 字节
return fmt.Errorf("expected 8 bytes, got %d", n)
}
return err
}
// 不推荐：容易写错边界
n := 0
for n
<h3>容易被忽略的底层 Reader 兼容性问题</h3>
<p><code>io.ReadFull</code> 本身不关心 Reader 类型，但某些 Reader 的行为会让结果难预测：</p>
-
bytes.Reader和strings.Reader：行为最稳定，适合单元测试 -
net.Conn：TCP 是流式协议，ReadFull可能阻塞等待剩余字节，但若对端关闭连接且未发够数据，就报io.ErrUnexpectedEOF -
bufio.Reader：如果缓冲区已空且底层 Reader 无法提供足够字节，同样触发io.ErrUnexpectedEOF；注意别在同一个bufio.Reader上混用Read和ReadFull，缓冲区状态可能被意外消费
真正麻烦的是加密 Reader（如 crypto/cipher.StreamReader）或压缩 Reader（如 gzip.Reader）：它们内部可能因解密/解压失败提前返回 EOF，这时 io.ReadFull 会把底层错误包装成 io.ErrUnexpectedEOF，丢失原始错误类型。遇到这类 Reader，优先考虑用 io.Read 手动控制流程。
