io.readall适合读取全部剩余数据，自动扩容至eof；io.readfull要求填满缓冲区，未满即报io.errunexpectedeof；前者易oom需限长，后者适用于固定长度协议头。
io.ReadAll 适合“读完为止”的场景
当你明确要拿走 io.Reader 的全部剩余数据（比如 HTTP 响应体、配置文件内容、TCP 连接关闭前的整块 payload），io.ReadAll 是最直接的选择。它内部自动扩容缓冲区，直到遇到 io.EOF 或其他错误，返回完整 []byte。
常见误用：io.ReadAll 不检查数据长度是否符合预期——哪怕源只写了 2 字节，它也 happily 返回那 2 字节，不报错。这在协议解析中容易埋坑。
- 适用：HTTP body、小文件、字符串模拟 reader、日志采集等“内容完整即有效”的场景
- 不适用：需要严格校验长度的二进制协议头、固定帧结构、或内存敏感的大流（可能 OOM）
- 注意：
io.ReadAll在 Go 1.16+ 已从ioutil.ReadAll移入io.ReadAll，旧代码需改导入
io.ReadFull 要求“必须填满缓冲区”
io.ReadFull 的行为很刚性：传入一个 buf []byte，它会反复调用底层 Read，直到填满整个 buf 或出错。只要没填满，就返回 io.ErrUnexpectedEOF，哪怕只剩 1 字节没读到。
典型错误现象：n, err := io.ReadFull(r, buf) 后直接打印 string(buf)，但 err == io.ErrUnexpectedEOF 时 n 可能是 0 或部分值，此时 buf 内容不可信。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 适用：读取协议头（如 4 字节 magic number、8 字节 length field）、TLS record header 等固定长度字段
- 不适用：读取不定长内容、HTTP body、用户输入流——这些天然可能提前 EOF
- 关键点：必须用
n截取有效字节，string(buf[:n])才安全；不能直接用string(buf)
两者对错误处理的逻辑根本不同
io.ReadAll 把 io.EOF 当作成功信号，只在真正出错（网络中断、权限拒绝等）时返回非 nil error；而 io.ReadFull 把任何未填满都视为失败，io.EOF 和 io.ErrUnexpectedEOF 都是 error，且语义不同：
-
io.EOF：说明 reader 已彻底耗尽，连 1 字节都不剩了（极少见于ReadFull，多见于单次Read） -
io.ErrUnexpectedEOF：reader 还有数据，但不够填满buf—— 这才是ReadFull最常返回的 error - 别用
errors.Is(err, io.EOF)判断ReadFull是否“读完了”，它永远不认为“读完”是成功
大文件或流式连接要防内存失控
io.ReadAll 没有长度上限，如果 reader 来自恶意客户端或失控服务（比如 TCP 连接一直不关），它会不断分配内存直到 OOM。生产环境必须加保护：
- 用
io.LimitedReader包一层：limited := &io.LimitedReader{R: r, N: 10 * 1024 * 1024}（限制 10MB） - 结合 context 设置超时：
ctx, cancel := context.WithTimeout(context.Background(), 5*time.Second)，并在 reader 实现中响应ctx.Done() -
io.ReadFull相对安全，因为缓冲区大小固定，但要注意：若反复重试读同一段失败的流，可能掩盖真实问题（比如连接已断但没及时检测）
真正难处理的是“半截协议”：比如期望读 8 字节长度字段，ReadFull 失败后你得决定是丢弃连接、重试，还是切到别的解析逻辑——这部分没法靠函数自动兜底。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
