io.reader.read不能只看err就退出，因为read是“能读多少给多少”而非“读完才返回”，n>0时必须先处理p[:n]再判err；推荐优先使用io.readall或io.copy，手动循环仅适用于流控等特殊场景。
io.Reader.Read 方法为什么不能只看 err 就退出
因为 Read 不是“读完才返回”，而是“能读多少给多少”。你传一个 buf := make([]byte, 4096)，它可能只写入 17 字节就返回 n = 17, err = nil——这完全合法，尤其在 HTTP chunked 响应、网络延迟或 gzip 流中高频出现。
常见错误写法：for { n, err := r.Read(buf); if err != nil { break } /* 忽略 buf[:n] */ }
结果是丢掉已读数据，还可能卡死（比如 err == io.EOF 但 n > 0 时本该处理最后一块）。
- 正确顺序永远是：先处理
buf[:n]（只要n > 0），再根据err判断后续 -
n > 0 && err == io.EOF：正常结束，本次数据有效 -
n == 0 && err == io.EOF：空流，也合法（如空响应体） -
n == 0 && err == nil：非法状态，标准库实现绝不会返回，自定义Reader返回这个组合会 panic
什么时候该用 io.ReadAll 而不是手写 for 循环
io.ReadAll 是绝大多数一次性读取场景的首选，它内部已处理分块、io.EOF、中间错误传播，且逻辑无遗漏。
- 适用场景：解析 JSON/YAML 配置、读小文件（
- 返回
[]byte，直接转字符串：string(data) - ⚠️ 大文件慎用：整个流加载进内存，OOM 风险高
- 旧代码里的
ioutil.ReadAll已弃用，必须换成io.ReadAll
io.Copy 比手动复制更可靠的原因
io.Copy(dst, src) 不只是“复制”，它是流式搬运工：自动用 32KB 缓冲区、正确传播错误、识别 io.EOF 并干净退出、支持 WriterTo/ReaderFrom 优化路径（如文件到文件可零拷贝）。
- 适用场景：HTTP body 转发、文件拷贝、管道中继（如
os.Stdout接收网络流） - 内存占用恒定，不随数据量增长
- 别自己写
for { n, _ := src.Read(buf); dst.Write(buf[:n]) }—— 容易漏err检查、忽略n == 0边界、无法利用底层优化 - 若需限速或逐帧处理，才考虑手动循环，但必须严格遵循“先用
buf[:n]，再判err”原则
HTTP Body 和 strings.NewReader 的典型陷阱
http.Response.Body 是一次性的 io.Reader，而 strings.NewReader 是零分配的内存 Reader，二者行为差异极大，容易误用。
-
resp.Body读完必须调用resp.Body.Close()，否则连接无法复用，连接池缓慢耗尽 -
resp.Body不支持 rewind；想多次读（比如先 inspect header 再解码 JSON），得先data, _ := io.ReadAll(resp.Body)，再用bytes.NewReader(data)构造新 Reader -
strings.NewReader(s)只是维护一个偏移指针，不 copy 字符串内容，性能好，但注意它返回的Reader不是线程安全的（并发读需加锁或复制） - 自定义
Reader里禁止阻塞：加time.Sleep、解密、正则匹配都会让json.Decoder或http.Transport误判为 IO 延迟，引发超时或死锁
实际编码中，最常被跳过的细节是：Read 的契约不是“填满切片”，而是“交付可用数据”；所有辅助函数（ReadAll、Copy）都基于这个前提构建。一旦手动循环，就等于主动接管这个契约——而多数人没意识到自己接不住。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
