该用io.readall当需一次性获取小数据（≤10mb）的[]byte或string，如json响应、配置文件；该用io.copy当需流式转发、大文件落地或写入另一io.writer，因其内存恒定、不oom。
什么时候该用 io.ReadAll 而不是 io.Copy
当你需要把整个流内容一次性转成 []byte 或 string，且确定数据量小（通常 ≤ 10MB），就直接用 io.ReadAll。比如解析 JSON 响应、读取配置文件、处理短 HTTP body。
常见错误现象：用 io.Copy 把 resp.Body 复制到 bytes.Buffer，再调 buf.Bytes()——多此一举，还绕过 io.ReadAll 内部的预分配优化（初始容量 512 字节，扩容策略更友好）。
- 性能影响：对平均 16KB 的小文件，
io.ReadAll比io.Copy+bytes.Buffer快 15–30%，因跳过了通用缓冲逻辑和中间写入步骤 - 内存代价：它会把全部内容加载进内存；万级小文件（如 10K × 16KB）≈ 160MB，得确认 GC 压力是否可接受
- 别用
ioutil.ReadFile（已弃用）：它内部调了os.Stat多一次系统调用，不如手动os.Open+io.ReadAll
什么时候必须用 io.Copy 替代 io.ReadAll
当你在做流式转发、大文件落地、或目标是另一个 io.Writer（如文件、网络连接、pipe），就必须用 io.Copy。它不攒内存，只用固定 32KB 缓冲区边读边写。
典型错误：用 io.ReadAll(resp.Body) 拿到大响应体（如 200MB 视频），再 os.WriteFile —— 瞬间 OOM，GC 频繁抖动，压测毛刺飙升。
Go 配置库，使用 spf13/viper — 分层优先级（flag > env >file > KV > default），提供 BindPFlag/BindPFlags、SetEnvPrefix + SetEnvKeyReplace 等功能。
- 兼容性：如果
src实现了WriteTo（如*os.File）或dst实现了ReadFrom（如*os.File），io.Copy会直连底层，零拷贝转发 - HTTP body 转发场景：直接
io.Copy(w, resp.Body)，比先读再写快且稳；但记得resp.Body.Close()后续不能再读 - 注意
io.Copy返回的是int64写入字节数，不是error优先判断项；err 为nil才代表成功传完
io.ReadAll 的边界陷阱与正确用法
io.ReadAll 看似简单，但几个细节不注意就会丢数据或 panic。
最常踩的坑：以为 err == io.EOF 才算读完，于是写 if err == io.EOF { break }，却忽略 n > 0 && err == nil 时仍有有效数据没处理。
- 它内部循环里每次
r.Read(b[len(b):cap(b)])，返回的n可能远小于切片剩余空间（尤其网络流、gzip 流），必须信任n值 - 不要自己封装
for { n, err := r.Read(buf) }去替代io.ReadAll—— 容易漏掉n > 0 && err == io.EOF这种合法终态 - 若需带限流或预估大小，可用
bytes.Buffer.Grow(n)配合io.Copy，但别手写 Read 循环
HTTP 响应体读取后还想重用？别依赖 io.ReadAll
http.Response.Body 是一次性 io.Reader，io.ReadAll 读完它就空了，再读会返回 io.EOF，且不支持 Seek（除非你把它包装成 bytes.Reader）。
错误做法：反复调 io.ReadAll(resp.Body) 想多次获取内容——第二次开始就啥也没有。
- 正确路径：一次
io.ReadAll(resp.Body)拿到完整data，然后用bytes.NewReader(data)创建新 Reader 供后续多次使用 - 如果只是想先看 header 再读 body，别省那点内存：直接全读，再用
json.NewDecoder(bytes.NewReader(data))解析，比反复打开连接更可靠 - 忘记
resp.Body.Close()？连接池泄漏，后续请求可能卡住或超时
io.ReadAll，后者闭眼用 io.Copy。大文件、流式、转发、写磁盘，一律避开 io.ReadAll —— 它不是慢，是根本不在那个设计契约里。
