应优先使用 io.ReadAll 或 io.Copy：小数据一次性读取用 io.ReadAll，大数据流式传输用 io.Copy；手动 for 循环仅适用于流控、限速等特殊场景，且必须先处理 buf[:n] 再判 err。
别手写 for 循环读 io.Reader，90% 的场景用 io.ReadAll 或 io.Copy 就够了；手动循环只在流控、逐帧解析等少数场景才必要，且必须先处理 buf[:n] 再判断 err。
为什么不能只看 err 就退出循环
io.Reader.Read 不保证填满你传的切片。比如传 buf := make([]byte, 4096)，它可能只写入 7 字节就返回 n = 7, err = nil——这完全合法，尤其在网络响应、gzip 分块或慢设备中极为常见。
常见错误写法：
for {
n, err := r.Read(buf)
if err != nil { // 错！这里会丢掉 buf[:n] 的数据
break
}
// 处理 buf，但没用 buf[:n]
}
正确逻辑永远是：
立即学习“go语言免费学习笔记（深入）”；
- 只要
n > 0，立刻处理buf[:n] - 再根据
err判断后续：err == io.EOF表示正常结束；err != nil && n > 0是“读了一半出错”，通常要保留已读数据；n == 0 && err == nil是非法状态，标准库实现绝不会返回
io.ReadAll 和 io.Copy 怎么选
两者都内部处理了分块、io.EOF、错误传播，不用你操心边界逻辑。
- 想一次性拿到全部内容（如 JSON 响应、小配置、YAML 文件）→ 用
io.ReadAll(r)，返回[]byte，再转string(data) - 想把数据从 A 流倒进 B 流（如 HTTP body 转发、文件拷贝、日志管道）→ 用
io.Copy(dst, src)，它用 32KB 缓冲区，内存占用恒定 -
io.ReadAll会把整个流加载进内存，大文件（>10MB）慎用；io.Copy没这问题
HTTP Body 读完不 Close() 会怎样
http.Response.Body 是一次性的 io.Reader，底层是网络连接。
- 读完不调用
resp.Body.Close()→ 连接无法复用，连接池慢慢耗尽，后续请求变慢甚至超时 - 想多次读（比如先看 header 再解析 body）→ 必须自己缓存：
data, _ := io.ReadAll(resp.Body)，然后用bytes.NewReader(data)或bytes.NewBuffer(data)构造新Reader -
strings.NewReader("")第一次Read就返回n = 0, err = io.EOF，不是空切片，也不能重读
自定义 io.Reader 最容易踩的坑
实现 io.Reader 接口 ≠ 写个“带 sleep 的读函数”。它的契约是：每次调用 Read(p []byte) 应尽快返回，让调用方控制节奏。
- 在
Read里加time.Sleep、解密、正则匹配 → 下游如json.Decoder或http.Transport会误判为 IO 延迟，触发超时、重试甚至死锁 - 需要流式处理（gzip/base64）？直接用标准包装器：
gzip.NewReader(r)或base64.NewDecoder(enc, r) - 字符串转
Reader？用strings.NewReader(s)，它只是指针偏移，不分配新内存，性能好；但注意它不可 rewind
最常被忽略的点：io.Reader 的设计哲学是「按需拉取」，不是「等齐了再给」；所有手动循环都得显式处理 n 和 err 的组合，而不仅仅是依赖 err 做流程判断。
