io.ReadFull 返回 io.ErrUnexpectedEOF 表示未读满指定字节数即遇 EOF，适用于需严格读取固定长度的场景；替代方案有 io.ReadAtLeast 和 io.Read。
io.ReadFull 为什么总返回 io.ErrUnexpectedEOF
这个错误不是表示文件读完了，而是你给的缓冲区太小，没填满就遇到 EOF。比如用 io.ReadFull 读 8 字节，但源数据只剩 3 字节，它就直接返回 io.ErrUnexpectedEOF，而不是把这 3 字节放进缓冲区再告诉你“只读了这么点”。
- 适用场景：需要**严格保证读够指定字节数**，如解析固定头结构（magic number、长度字段）
- 替代方案：
io.ReadAtLeast允许读到最少 N 字节（可多不可少）；io.Read更灵活，返回实际读取数 - 常见误用：拿它当普通读取函数，结果一遇到短数据就 panic 或逻辑中断
用 io.Copy 时如何带进度和限速
io.Copy 本身不支持回调或限速，但你可以包装一个带控制逻辑的 io.Reader 或 io.Writer。
- 进度上报：写个 wrapper
io.Reader，每次Read后累加字节数并触发回调 - 限速实现：在
Read中 sleep，例如每读 64KB 睡 10ms，等效约 6.4MB/s - 注意：
io.Copy内部用 32KB 缓冲区，频繁 sleep 会影响吞吐，建议用更大的单次读尺寸配合更粗粒度的限速
type RateLimitedReader struct {
r io.Reader
limit time.Duration
last time.Time
}
func (r *RateLimitedReader) Read(p []byte) (n int, err error) {
now := time.Now()
if since := now.Sub(r.last); since < r.limit {
time.Sleep(r.limit - since)
}
r.last = time.Now()
return r.r.Read(p)
}
io.MultiWriter 和 io.TeeReader 的真实分工
两者都做“复制”，但方向和时机完全不同：
-
io.MultiWriter是写入时**广播**：所有传入的io.Writer都会收到同一份数据，常用于日志同时写文件+网络+内存缓冲 -
io.TeeReader是读取时**分流**：主流程读数据的同时，把每个字节同步写进另一个io.Writer（比如边解压边计算 SHA256），它不缓存，也不改变原读取行为 - 别混淆成“Tee 是写、MultiWriter 是读”——它们的命名都基于主操作方向：
TeeReader主体是Read，MultiWriter主体是Write
为什么 os.File 实现 io.ReaderAt 和 io.WriterAt 很关键
这两个接口允许随机偏移读写，绕过当前文件指针位置。对大文件分块上传、断点续传、内存映射式解析特别有用。
立即学习“go语言免费学习笔记（深入）”；
-
ReadAt不会移动文件指针，适合并发读不同 offset 区域 -
WriteAt常用于 patch 场景，比如只更新 ELF 文件的某一段 header，不用重写整个文件 - 注意：Windows 下
WriteAt可能不原子，且某些文件系统（如 FAT32）不支持；Linux ext4/xfs 支持良好 - 别直接用
file.Seek + Read替代ReadAt—— 并发时 Seek 会互相干扰
实际用多了会发现，io 包的抽象看似简单，但每个接口的契约（比如是否移动 offset、是否保证字节数、是否并发安全）稍不留意就会埋坑。尤其是组合多个 wrapper 时，顺序和所有权容易出错——比如把 io.TeeReader 套在 gzip.Reader 外面，SHA 计算的是压缩后字节，而你本意可能是原始内容。
