io.ReadFull总返回io.ErrUnexpectedEOF，因其设计要求必须读满指定字节数，少一字节即报错，专用于定长协议解析而非通用读取。
Go 的 io 包本身不直接打开文件，它只定义接口和通用函数；真正做读写动作前，必须先用 os 包拿到 *os.File（它实现了 io.Reader 和 io.Writer）。
为什么 io.ReadAll 有时读不出内容？
常见现象：调用 io.ReadAll(file) 返回空字节切片，但文件明明有内容。
- 最常被忽略的是：文件指针已在开头，但你之前已调用过
file.Read或bufio.Scanner.Scan()—— 指针已移到末尾，再ReadAll就什么也读不到 -
os.Open打开的文件默认从开头读，但一旦读过一次，后续读取会继续从当前偏移位置开始 - 修复方法：用
file.Seek(0, io.SeekStart)重置指针，或重新os.Open - 注意：
io.ReadAll不会自动关闭文件，也不改变文件状态，它只是“把当前指针往后一直读到 EOF”
io.Copy 和 io.WriteString 的实际使用边界
这两个函数看似简单，但参数类型和行为差异直接影响是否能跑通：
-
io.Copy(dst io.Writer, src io.Reader)：适合管道式转发，比如把文件内容拷到网络连接、另一个文件或bytes.Buffer；它内部循环调用Read和Write，不缓存整块数据，内存友好 -
io.WriteString(w io.Writer, s string)：只写字符串，不换行，不加任何分隔符；常用于日志追加或协议头写入；如果目标是*os.File，它等价于w.Write([]byte(s))，但更简洁 - 错误陷阱：
io.Copy的dst如果是只读的*os.File（比如用os.Open打开），会报bad file descriptor—— 因为没写权限 - 别传
nil：io.Copy(nil, reader)会 panic，哪怕你想丢弃数据，也要用io.Discard
大文件分块读写时，缓冲区大小怎么选？
不是越大越好，也不是固定 4KB 最优；关键看场景和系统页大小：
立即学习“go语言免费学习笔记（深入）”；
- 典型值用
32 * 1024（32KB）或64 * 1024（64KB），在多数 Linux 系统上接近 page cache 效率拐点 - 小于 4KB（如 1KB）会导致系统调用太频繁，CPU 花在 syscall 上的时间占比升高
- 大于 1MB 容易触发 GC 压力，尤其当多个 goroutine 并发使用大 buffer 时
- 如果配合
bufio.NewReaderSize，建议 buffer 大小设为 2 的幂次（如 8192），避免内部切片扩容 - 实测建议：对 SSD 介质，64KB 缓冲通常比 4KB 快 3–5 倍；对机械盘，32KB 更稳
为什么 io.ReadFull 总返回 io.ErrUnexpectedEOF？
这不是错误，而是明确语义：它要求“必须读满指定长度”，少一个字节就算失败。
- 适用场景有限：只用于协议解析（如固定头长的二进制包）、校验读取完整性，**不适合普通文件内容读取**
- 常见误用：拿它替代
io.Read或io.ReadAll，结果一遇到最后一块不足缓冲区大小就报错 - 正确做法：
io.ReadFull应配合已知长度的预期（比如读 TCP 包头 4 字节），且需手动处理io.ErrUnexpectedEOF分支 - 替代方案：用
io.ReadAtLeast（至少读多少）或直接用Read+ 检查返回的n
真正容易被忽略的，是 io 函数不管理资源生命周期 —— 它们从不打开、不关闭、不创建文件，只管“流式搬运”。所有文件句柄、网络连接、buffer 的生命周期，都得你自己用 defer 或显式 Close 控制。漏掉这一环，跑几天后就会出现 too many open files。
